Re: Notice of withdrawal of CI services: KDevelop and KDE Connect
On Fri, Jun 18, 2021 at 7:33 AM Milian Wolff wrote: > On Donnerstag, 17. Juni 2021 11:25:15 CEST Ben Cooksley wrote: > > On Thu, Jun 17, 2021 at 8:44 AM Milian Wolff wrote: > > > On Mittwoch, 16. Juni 2021 20:28:25 CEST Ben Cooksley wrote: > > > > Hi all, > > > > > > > > > > > > The following is notice that I intend to withdraw CI services from > the > > > > following two KDE projects due to faults in their code or build > system > > > > which are having a significant adverse impact on the CI system and > > > > negatively impacting on other projects: > > > > > > > > - KDevelop > > > > - KDE Connect > > > > > > > > This withdrawal will be applied to all platforms. > > > > > > > > In the case of KDevelop, it has a series of unit tests which on > FreeBSD > > > > cause gdb to hang and consume an entire CPU core indefinitely. This > > > > slows > > > > down builds for all other projects using that CI server, and also > > > > > > prevents > > > > > > > KWin tests from proceeding - completely blocking it's jobs. This > fault > > > > is > > > > in the debuggee_slow family of tests. > > > > > > Hey Ben, > > > > Hi Milian, > > > > > first time I hear of this issue. I simply don't have the capacity to > track > > > kdevelop CI mails, so if anything really bad happens, I would really > > > appreciate if anyone who notices that sents a mail to the kdevelop > mailing > > > list so we can act on it. I still use kdevelop daily, but don't put any > > > other > > > work in it currently due to lack of time... > > > > The issue in question was noted on #kdevelop (prior to the whole Freenode > > meltdown) on a few occasions. > > Even before that meltdown, I only looked at this when I was directly > pinged. > Please prefer to use the mailing lists to get our attention. > Certainly. > > > > That said: can we just disable it on the FreeBSD platform, if that's > the > > > only > > > one that exhibits this failure? Alternatively I'm obviously fine with > > > skipping > > > that test on that platform, can you give me a link to a failure please > so > > > I > > > can see which tests exactly are affected? Then I'll add the QSKIP + > > > platform > > > ifdef checks to skip it on freebsd. > > > > I'm afraid I only have records of the hung test processes (and the gdb > > processes above them using an entire CPU core indefinitely each). > > > > jenkins60635 0.0 0.0 12120 2256 0 TXs+ 02:44 0:00.00 > > /usr/home/jenkins/workspace/KDevelop/kdevelop/kf5-qt5 > > > FreeBSDQt5.15/build/plugins/debuggercommon/tests/debuggees/debuggee_debugees > > low (debuggee_debugeeslo) > > jenkins74167 0.0 0.0 12120 2260 1 TXs+ 02:55 0:00.00 > > /usr/home/jenkins/workspace/KDevelop/kdevelop/kf5-qt5 > > > FreeBSDQt5.15/build/plugins/debuggercommon/tests/debuggees/debuggee_debugees > > low (debuggee_debugeeslo) > > > > Hopefully that is enough to identify the tests that are broken? > > I have now added code to skip the tests on FreeBSD wherever debuggeeslow > is > used. Unsure which test of the many is actually triggering it, but I have > no > time to invest on this either. > > So, is that acceptable for you for now? > That should be perfectly fine - thanks for skipping those tests on FreeBSD. Please note that it is possible the issue also occurs on Linux however we've no way of knowing if this is the case as the Docker containers are used for one build only and then thrown away (which is also why it isn't an issue there if it is happening, as the process of throwing away the container will kill off any leftover processes) Cheers, Ben > Cheers > > -- > Milian Wolff > m...@milianw.de > http://milianw.de
Re: Notice of withdrawal of CI services: KDevelop and KDE Connect
On Fri, Jun 18, 2021 at 7:33 AM Milian Wolff wrote: > On Donnerstag, 17. Juni 2021 11:25:15 CEST Ben Cooksley wrote: > > On Thu, Jun 17, 2021 at 8:44 AM Milian Wolff wrote: > > > On Mittwoch, 16. Juni 2021 20:28:25 CEST Ben Cooksley wrote: > > > > Hi all, > > > > > > > > > > > > The following is notice that I intend to withdraw CI services from > the > > > > following two KDE projects due to faults in their code or build > system > > > > which are having a significant adverse impact on the CI system and > > > > negatively impacting on other projects: > > > > > > > > - KDevelop > > > > - KDE Connect > > > > > > > > This withdrawal will be applied to all platforms. > > > > > > > > In the case of KDevelop, it has a series of unit tests which on > FreeBSD > > > > cause gdb to hang and consume an entire CPU core indefinitely. This > > > > slows > > > > down builds for all other projects using that CI server, and also > > > > > > prevents > > > > > > > KWin tests from proceeding - completely blocking it's jobs. This > fault > > > > is > > > > in the debuggee_slow family of tests. > > > > > > Hey Ben, > > > > Hi Milian, > > > > > first time I hear of this issue. I simply don't have the capacity to > track > > > kdevelop CI mails, so if anything really bad happens, I would really > > > appreciate if anyone who notices that sents a mail to the kdevelop > mailing > > > list so we can act on it. I still use kdevelop daily, but don't put any > > > other > > > work in it currently due to lack of time... > > > > The issue in question was noted on #kdevelop (prior to the whole Freenode > > meltdown) on a few occasions. > > Even before that meltdown, I only looked at this when I was directly > pinged. > Please prefer to use the mailing lists to get our attention. > Certainly. > > > > That said: can we just disable it on the FreeBSD platform, if that's > the > > > only > > > one that exhibits this failure? Alternatively I'm obviously fine with > > > skipping > > > that test on that platform, can you give me a link to a failure please > so > > > I > > > can see which tests exactly are affected? Then I'll add the QSKIP + > > > platform > > > ifdef checks to skip it on freebsd. > > > > I'm afraid I only have records of the hung test processes (and the gdb > > processes above them using an entire CPU core indefinitely each). > > > > jenkins60635 0.0 0.0 12120 2256 0 TXs+ 02:44 0:00.00 > > /usr/home/jenkins/workspace/KDevelop/kdevelop/kf5-qt5 > > > FreeBSDQt5.15/build/plugins/debuggercommon/tests/debuggees/debuggee_debugees > > low (debuggee_debugeeslo) > > jenkins74167 0.0 0.0 12120 2260 1 TXs+ 02:55 0:00.00 > > /usr/home/jenkins/workspace/KDevelop/kdevelop/kf5-qt5 > > > FreeBSDQt5.15/build/plugins/debuggercommon/tests/debuggees/debuggee_debugees > > low (debuggee_debugeeslo) > > > > Hopefully that is enough to identify the tests that are broken? > > I have now added code to skip the tests on FreeBSD wherever debuggeeslow > is > used. Unsure which test of the many is actually triggering it, but I have > no > time to invest on this either. > > So, is that acceptable for you for now? > That should be perfectly fine - thanks for skipping those tests on FreeBSD. Please note that it is possible the issue also occurs on Linux however we've no way of knowing if this is the case as the Docker containers are used for one build only and then thrown away (which is also why it isn't an issue there if it is happening, as the process of throwing away the container will kill off any leftover processes) Cheers, Ben > Cheers > > -- > Milian Wolff > m...@milianw.de > http://milianw.de
Re: Notice of withdrawal of CI services: KDevelop and KDE Connect
On Donnerstag, 17. Juni 2021 11:25:15 CEST Ben Cooksley wrote: > On Thu, Jun 17, 2021 at 8:44 AM Milian Wolff wrote: > > On Mittwoch, 16. Juni 2021 20:28:25 CEST Ben Cooksley wrote: > > > Hi all, > > > > > > > > > The following is notice that I intend to withdraw CI services from the > > > following two KDE projects due to faults in their code or build system > > > which are having a significant adverse impact on the CI system and > > > negatively impacting on other projects: > > > > > > - KDevelop > > > - KDE Connect > > > > > > This withdrawal will be applied to all platforms. > > > > > > In the case of KDevelop, it has a series of unit tests which on FreeBSD > > > cause gdb to hang and consume an entire CPU core indefinitely. This > > > slows > > > down builds for all other projects using that CI server, and also > > > > prevents > > > > > KWin tests from proceeding - completely blocking it's jobs. This fault > > > is > > > in the debuggee_slow family of tests. > > > > Hey Ben, > > Hi Milian, > > > first time I hear of this issue. I simply don't have the capacity to track > > kdevelop CI mails, so if anything really bad happens, I would really > > appreciate if anyone who notices that sents a mail to the kdevelop mailing > > list so we can act on it. I still use kdevelop daily, but don't put any > > other > > work in it currently due to lack of time... > > The issue in question was noted on #kdevelop (prior to the whole Freenode > meltdown) on a few occasions. Even before that meltdown, I only looked at this when I was directly pinged. Please prefer to use the mailing lists to get our attention. > > That said: can we just disable it on the FreeBSD platform, if that's the > > only > > one that exhibits this failure? Alternatively I'm obviously fine with > > skipping > > that test on that platform, can you give me a link to a failure please so > > I > > can see which tests exactly are affected? Then I'll add the QSKIP + > > platform > > ifdef checks to skip it on freebsd. > > I'm afraid I only have records of the hung test processes (and the gdb > processes above them using an entire CPU core indefinitely each). > > jenkins60635 0.0 0.0 12120 2256 0 TXs+ 02:44 0:00.00 > /usr/home/jenkins/workspace/KDevelop/kdevelop/kf5-qt5 > FreeBSDQt5.15/build/plugins/debuggercommon/tests/debuggees/debuggee_debugees > low (debuggee_debugeeslo) > jenkins74167 0.0 0.0 12120 2260 1 TXs+ 02:55 0:00.00 > /usr/home/jenkins/workspace/KDevelop/kdevelop/kf5-qt5 > FreeBSDQt5.15/build/plugins/debuggercommon/tests/debuggees/debuggee_debugees > low (debuggee_debugeeslo) > > Hopefully that is enough to identify the tests that are broken? I have now added code to skip the tests on FreeBSD wherever debuggeeslow is used. Unsure which test of the many is actually triggering it, but I have no time to invest on this either. So, is that acceptable for you for now? Cheers -- Milian Wolff m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part.
Re: Notice of withdrawal of CI services: KDevelop and KDE Connect
On Donnerstag, 17. Juni 2021 11:25:15 CEST Ben Cooksley wrote: > On Thu, Jun 17, 2021 at 8:44 AM Milian Wolff wrote: > > On Mittwoch, 16. Juni 2021 20:28:25 CEST Ben Cooksley wrote: > > > Hi all, > > > > > > > > > The following is notice that I intend to withdraw CI services from the > > > following two KDE projects due to faults in their code or build system > > > which are having a significant adverse impact on the CI system and > > > negatively impacting on other projects: > > > > > > - KDevelop > > > - KDE Connect > > > > > > This withdrawal will be applied to all platforms. > > > > > > In the case of KDevelop, it has a series of unit tests which on FreeBSD > > > cause gdb to hang and consume an entire CPU core indefinitely. This > > > slows > > > down builds for all other projects using that CI server, and also > > > > prevents > > > > > KWin tests from proceeding - completely blocking it's jobs. This fault > > > is > > > in the debuggee_slow family of tests. > > > > Hey Ben, > > Hi Milian, > > > first time I hear of this issue. I simply don't have the capacity to track > > kdevelop CI mails, so if anything really bad happens, I would really > > appreciate if anyone who notices that sents a mail to the kdevelop mailing > > list so we can act on it. I still use kdevelop daily, but don't put any > > other > > work in it currently due to lack of time... > > The issue in question was noted on #kdevelop (prior to the whole Freenode > meltdown) on a few occasions. Even before that meltdown, I only looked at this when I was directly pinged. Please prefer to use the mailing lists to get our attention. > > That said: can we just disable it on the FreeBSD platform, if that's the > > only > > one that exhibits this failure? Alternatively I'm obviously fine with > > skipping > > that test on that platform, can you give me a link to a failure please so > > I > > can see which tests exactly are affected? Then I'll add the QSKIP + > > platform > > ifdef checks to skip it on freebsd. > > I'm afraid I only have records of the hung test processes (and the gdb > processes above them using an entire CPU core indefinitely each). > > jenkins60635 0.0 0.0 12120 2256 0 TXs+ 02:44 0:00.00 > /usr/home/jenkins/workspace/KDevelop/kdevelop/kf5-qt5 > FreeBSDQt5.15/build/plugins/debuggercommon/tests/debuggees/debuggee_debugees > low (debuggee_debugeeslo) > jenkins74167 0.0 0.0 12120 2260 1 TXs+ 02:55 0:00.00 > /usr/home/jenkins/workspace/KDevelop/kdevelop/kf5-qt5 > FreeBSDQt5.15/build/plugins/debuggercommon/tests/debuggees/debuggee_debugees > low (debuggee_debugeeslo) > > Hopefully that is enough to identify the tests that are broken? I have now added code to skip the tests on FreeBSD wherever debuggeeslow is used. Unsure which test of the many is actually triggering it, but I have no time to invest on this either. So, is that acceptable for you for now? Cheers -- Milian Wolff m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part.
Re: Notice of withdrawal of CI services: KDevelop and KDE Connect
On Thu, Jun 17, 2021 at 7:26 AM Avamander wrote: > Hi, > Hi there, > > This is indeed an issue that has occurred previously, and actually > I've written to you, Ben, once before about this. Now I'm asking again, why > is it necessary to email *FIVE* mailing lists for issues that are > primarily solved by a much much smaller subgroup of people? Maybe send it > to a few C++ lists as well, maybe someone'll jump out and fix the CI 浪 > According to my email archives we've not previously corresponded - and the name "Avamander" is certainly new to me. The five lists in question were chosen deliberately for the following reasons: 1) kdeconn...@kde.org as the matter related to KDE Connect 2) kdevelop-de...@kde.org as the matter related to KDevelop 3) kde-frameworks-devel@kde.org as the email explained why Frameworks had experienced a substantial number of Windows CI failures lately 4) kde-de...@kde.org as the email explained to various Extragear projects why they had experienced Windows CI failures as well 5) sysad...@kde.org as the matter related to our infrastructure > On a very related topic, for the third time, send the kdeconnect CI status > emails to the actual developers and contributors for whom they are > actionable, not the entire kdeconnect mailing list. It's just noise for the > majority of non-code contributors, non-code contributors that might be able > to help with support questions but who are very likely ignoring the list > due to horrifically bad SNR. > Please direct your complaints regarding the content and moderation of the kdeconn...@kde.org to the list administrators - kdeconnect-ow...@kde.org - in the first instance or raise a thread on that mailing list. With regards to the CI status emails, these were setup at the request of the KDE Connect developers in https://phabricator.kde.org/D13794 > > > Have an extra day, > Avamander > Regards, Ben > > On Wed, Jun 16, 2021 at 9:29 PM Ben Cooksley wrote: > >> Hi all, >> >> The following is notice that I intend to withdraw CI services from the >> following two KDE projects due to faults in their code or build system >> which are having a significant adverse impact on the CI system and >> negatively impacting on other projects: >> >> - KDevelop >> - KDE Connect >> >> This withdrawal will be applied to all platforms. >> >> In the case of KDevelop, it has a series of unit tests which on FreeBSD >> cause gdb to hang and consume an entire CPU core indefinitely. This slows >> down builds for all other projects using that CI server, and also prevents >> KWin tests from proceeding - completely blocking it's jobs. This fault is >> in the debuggee_slow family of tests. >> >> As this issue has persisted for some time now despite being mentioned, I >> require that the family of tests in question be disabled across all >> platforms. >> >> In the case of KDE Connect, as part of it's configure process it runs an >> external command that results in dbus-daemon being launched. This process >> persists following the build and would only be cleaned up by our tooling >> that runs tests. Should the compilation fail (as it does currently) it will >> result in the CI builder being broken - which is why we have had so many >> Windows builds fail lately. >> >> As this is an issue that has occurred previously, I require that the >> configure time check which is launching dbus-daemon to be expunged from KDE >> Connect. >> >> As a reminder to all projects, running commands that interact with >> dbus-daemon or kdeinit is not permitted during configure or build time. >> >> Regards, >> Ben Cooksley >> KDE Sysadmin >> >
Re: Notice of withdrawal of CI services: KDevelop and KDE Connect
On Thu, Jun 17, 2021 at 7:26 AM Avamander wrote: > Hi, > Hi there, > > This is indeed an issue that has occurred previously, and actually > I've written to you, Ben, once before about this. Now I'm asking again, why > is it necessary to email *FIVE* mailing lists for issues that are > primarily solved by a much much smaller subgroup of people? Maybe send it > to a few C++ lists as well, maybe someone'll jump out and fix the CI 浪 > According to my email archives we've not previously corresponded - and the name "Avamander" is certainly new to me. The five lists in question were chosen deliberately for the following reasons: 1) kdeconn...@kde.org as the matter related to KDE Connect 2) kdevelop-de...@kde.org as the matter related to KDevelop 3) kde-frameworks-de...@kde.org as the email explained why Frameworks had experienced a substantial number of Windows CI failures lately 4) kde-devel@kde.org as the email explained to various Extragear projects why they had experienced Windows CI failures as well 5) sysad...@kde.org as the matter related to our infrastructure > On a very related topic, for the third time, send the kdeconnect CI status > emails to the actual developers and contributors for whom they are > actionable, not the entire kdeconnect mailing list. It's just noise for the > majority of non-code contributors, non-code contributors that might be able > to help with support questions but who are very likely ignoring the list > due to horrifically bad SNR. > Please direct your complaints regarding the content and moderation of the kdeconn...@kde.org to the list administrators - kdeconnect-ow...@kde.org - in the first instance or raise a thread on that mailing list. With regards to the CI status emails, these were setup at the request of the KDE Connect developers in https://phabricator.kde.org/D13794 > > > Have an extra day, > Avamander > Regards, Ben > > On Wed, Jun 16, 2021 at 9:29 PM Ben Cooksley wrote: > >> Hi all, >> >> The following is notice that I intend to withdraw CI services from the >> following two KDE projects due to faults in their code or build system >> which are having a significant adverse impact on the CI system and >> negatively impacting on other projects: >> >> - KDevelop >> - KDE Connect >> >> This withdrawal will be applied to all platforms. >> >> In the case of KDevelop, it has a series of unit tests which on FreeBSD >> cause gdb to hang and consume an entire CPU core indefinitely. This slows >> down builds for all other projects using that CI server, and also prevents >> KWin tests from proceeding - completely blocking it's jobs. This fault is >> in the debuggee_slow family of tests. >> >> As this issue has persisted for some time now despite being mentioned, I >> require that the family of tests in question be disabled across all >> platforms. >> >> In the case of KDE Connect, as part of it's configure process it runs an >> external command that results in dbus-daemon being launched. This process >> persists following the build and would only be cleaned up by our tooling >> that runs tests. Should the compilation fail (as it does currently) it will >> result in the CI builder being broken - which is why we have had so many >> Windows builds fail lately. >> >> As this is an issue that has occurred previously, I require that the >> configure time check which is launching dbus-daemon to be expunged from KDE >> Connect. >> >> As a reminder to all projects, running commands that interact with >> dbus-daemon or kdeinit is not permitted during configure or build time. >> >> Regards, >> Ben Cooksley >> KDE Sysadmin >> >
Re: Notice of withdrawal of CI services: KDevelop and KDE Connect
On Thu, Jun 17, 2021 at 8:44 AM Milian Wolff wrote: > On Mittwoch, 16. Juni 2021 20:28:25 CEST Ben Cooksley wrote: > > Hi all, > > > The following is notice that I intend to withdraw CI services from the > > following two KDE projects due to faults in their code or build system > > which are having a significant adverse impact on the CI system and > > negatively impacting on other projects: > > > > - KDevelop > > - KDE Connect > > > > This withdrawal will be applied to all platforms. > > > > In the case of KDevelop, it has a series of unit tests which on FreeBSD > > cause gdb to hang and consume an entire CPU core indefinitely. This slows > > down builds for all other projects using that CI server, and also > prevents > > KWin tests from proceeding - completely blocking it's jobs. This fault is > > in the debuggee_slow family of tests. > > Hey Ben, > Hi Milian, > > first time I hear of this issue. I simply don't have the capacity to track > kdevelop CI mails, so if anything really bad happens, I would really > appreciate if anyone who notices that sents a mail to the kdevelop mailing > list so we can act on it. I still use kdevelop daily, but don't put any > other > work in it currently due to lack of time... > The issue in question was noted on #kdevelop (prior to the whole Freenode meltdown) on a few occasions. > > That said: can we just disable it on the FreeBSD platform, if that's the > only > one that exhibits this failure? Alternatively I'm obviously fine with > skipping > that test on that platform, can you give me a link to a failure please so > I > can see which tests exactly are affected? Then I'll add the QSKIP + > platform > ifdef checks to skip it on freebsd. > I'm afraid I only have records of the hung test processes (and the gdb processes above them using an entire CPU core indefinitely each). jenkins60635 0.0 0.0 12120 2256 0 TXs+ 02:44 0:00.00 /usr/home/jenkins/workspace/KDevelop/kdevelop/kf5-qt5 FreeBSDQt5.15/build/plugins/debuggercommon/tests/debuggees/debuggee_debugeeslow (debuggee_debugeeslo) jenkins74167 0.0 0.0 12120 2260 1 TXs+ 02:55 0:00.00 /usr/home/jenkins/workspace/KDevelop/kdevelop/kf5-qt5 FreeBSDQt5.15/build/plugins/debuggercommon/tests/debuggees/debuggee_debugeeslow (debuggee_debugeeslo) Hopefully that is enough to identify the tests that are broken? > > Cheers and thanks for letting me know about this problem > > -- > Milian Wolff > m...@milianw.de > http://milianw.de Thanks, Ben
Re: Notice of withdrawal of CI services: KDevelop and KDE Connect
On Thu, Jun 17, 2021 at 8:44 AM Milian Wolff wrote: > On Mittwoch, 16. Juni 2021 20:28:25 CEST Ben Cooksley wrote: > > Hi all, > > > The following is notice that I intend to withdraw CI services from the > > following two KDE projects due to faults in their code or build system > > which are having a significant adverse impact on the CI system and > > negatively impacting on other projects: > > > > - KDevelop > > - KDE Connect > > > > This withdrawal will be applied to all platforms. > > > > In the case of KDevelop, it has a series of unit tests which on FreeBSD > > cause gdb to hang and consume an entire CPU core indefinitely. This slows > > down builds for all other projects using that CI server, and also > prevents > > KWin tests from proceeding - completely blocking it's jobs. This fault is > > in the debuggee_slow family of tests. > > Hey Ben, > Hi Milian, > > first time I hear of this issue. I simply don't have the capacity to track > kdevelop CI mails, so if anything really bad happens, I would really > appreciate if anyone who notices that sents a mail to the kdevelop mailing > list so we can act on it. I still use kdevelop daily, but don't put any > other > work in it currently due to lack of time... > The issue in question was noted on #kdevelop (prior to the whole Freenode meltdown) on a few occasions. > > That said: can we just disable it on the FreeBSD platform, if that's the > only > one that exhibits this failure? Alternatively I'm obviously fine with > skipping > that test on that platform, can you give me a link to a failure please so > I > can see which tests exactly are affected? Then I'll add the QSKIP + > platform > ifdef checks to skip it on freebsd. > I'm afraid I only have records of the hung test processes (and the gdb processes above them using an entire CPU core indefinitely each). jenkins60635 0.0 0.0 12120 2256 0 TXs+ 02:44 0:00.00 /usr/home/jenkins/workspace/KDevelop/kdevelop/kf5-qt5 FreeBSDQt5.15/build/plugins/debuggercommon/tests/debuggees/debuggee_debugeeslow (debuggee_debugeeslo) jenkins74167 0.0 0.0 12120 2260 1 TXs+ 02:55 0:00.00 /usr/home/jenkins/workspace/KDevelop/kdevelop/kf5-qt5 FreeBSDQt5.15/build/plugins/debuggercommon/tests/debuggees/debuggee_debugeeslow (debuggee_debugeeslo) Hopefully that is enough to identify the tests that are broken? > > Cheers and thanks for letting me know about this problem > > -- > Milian Wolff > m...@milianw.de > http://milianw.de Thanks, Ben
Re: Notice of withdrawal of CI services: KDevelop and KDE Connect
Hi, This is indeed an issue that has occurred previously, and actually I've written to you, Ben, once before about this. Now I'm asking again, why is it necessary to email *FIVE* mailing lists for issues that are primarily solved by a much much smaller subgroup of people? Maybe send it to a few C++ lists as well, maybe someone'll jump out and fix the CI 浪 On a very related topic, for the third time, send the kdeconnect CI status emails to the actual developers and contributors for whom they are actionable, not the entire kdeconnect mailing list. It's just noise for the majority of non-code contributors, non-code contributors that might be able to help with support questions but who are very likely ignoring the list due to horrifically bad SNR. Have an extra day, Avamander On Wed, Jun 16, 2021 at 9:29 PM Ben Cooksley wrote: > Hi all, > > The following is notice that I intend to withdraw CI services from the > following two KDE projects due to faults in their code or build system > which are having a significant adverse impact on the CI system and > negatively impacting on other projects: > > - KDevelop > - KDE Connect > > This withdrawal will be applied to all platforms. > > In the case of KDevelop, it has a series of unit tests which on FreeBSD > cause gdb to hang and consume an entire CPU core indefinitely. This slows > down builds for all other projects using that CI server, and also prevents > KWin tests from proceeding - completely blocking it's jobs. This fault is > in the debuggee_slow family of tests. > > As this issue has persisted for some time now despite being mentioned, I > require that the family of tests in question be disabled across all > platforms. > > In the case of KDE Connect, as part of it's configure process it runs an > external command that results in dbus-daemon being launched. This process > persists following the build and would only be cleaned up by our tooling > that runs tests. Should the compilation fail (as it does currently) it will > result in the CI builder being broken - which is why we have had so many > Windows builds fail lately. > > As this is an issue that has occurred previously, I require that the > configure time check which is launching dbus-daemon to be expunged from KDE > Connect. > > As a reminder to all projects, running commands that interact with > dbus-daemon or kdeinit is not permitted during configure or build time. > > Regards, > Ben Cooksley > KDE Sysadmin >
Re: Notice of withdrawal of CI services: KDevelop and KDE Connect
Hi, This is indeed an issue that has occurred previously, and actually I've written to you, Ben, once before about this. Now I'm asking again, why is it necessary to email *FIVE* mailing lists for issues that are primarily solved by a much much smaller subgroup of people? Maybe send it to a few C++ lists as well, maybe someone'll jump out and fix the CI 浪 On a very related topic, for the third time, send the kdeconnect CI status emails to the actual developers and contributors for whom they are actionable, not the entire kdeconnect mailing list. It's just noise for the majority of non-code contributors, non-code contributors that might be able to help with support questions but who are very likely ignoring the list due to horrifically bad SNR. Have an extra day, Avamander On Wed, Jun 16, 2021 at 9:29 PM Ben Cooksley wrote: > Hi all, > > The following is notice that I intend to withdraw CI services from the > following two KDE projects due to faults in their code or build system > which are having a significant adverse impact on the CI system and > negatively impacting on other projects: > > - KDevelop > - KDE Connect > > This withdrawal will be applied to all platforms. > > In the case of KDevelop, it has a series of unit tests which on FreeBSD > cause gdb to hang and consume an entire CPU core indefinitely. This slows > down builds for all other projects using that CI server, and also prevents > KWin tests from proceeding - completely blocking it's jobs. This fault is > in the debuggee_slow family of tests. > > As this issue has persisted for some time now despite being mentioned, I > require that the family of tests in question be disabled across all > platforms. > > In the case of KDE Connect, as part of it's configure process it runs an > external command that results in dbus-daemon being launched. This process > persists following the build and would only be cleaned up by our tooling > that runs tests. Should the compilation fail (as it does currently) it will > result in the CI builder being broken - which is why we have had so many > Windows builds fail lately. > > As this is an issue that has occurred previously, I require that the > configure time check which is launching dbus-daemon to be expunged from KDE > Connect. > > As a reminder to all projects, running commands that interact with > dbus-daemon or kdeinit is not permitted during configure or build time. > > Regards, > Ben Cooksley > KDE Sysadmin >
Re: Notice of withdrawal of CI services: KDevelop and KDE Connect
How about if we add a config flag for our ci machines and configure cmake of these 2 project's test to ignore building/adding those problematic tests whenever it saw those flags? I don't know why but it doesn't sound correct to me to kill the ci build of any project because of these types of problems. Ömer Fadıl Usta PGP key : 0xfd11561976b1690b about.me/omerusta Ben Cooksley , 16 Haz 2021 Çar, 21:57 tarihinde şunu yazdı: > On Thu, Jun 17, 2021 at 6:41 AM Nate Graham wrote: > >> This kind of problem will be generically solved for everyone once we get >> GitLab's pre-commit CI, which can block merging of MRs until the >> failures are resolved--so they actually *will* be resolved. How soon can >> we get that finally rolled out across KDE? >> > > I'm afraid GitLab CI wouldn't have prevented this from occurring - because > the pre-merge CI still needs to run somewhere. > The problem here is that the simple act of running the build > degrades/breaks the builders for everyone else. > > In terms of a timeline on this, once I have the situation with Nextcloud > sorted out (which had to be prioritised as the version we're on goes out of > support in the next few months) we'll hopefully be able to work on GitLab > CI (assuming another vendor of ours doesn't go and pull another major > dependency bump stunt like Nextcloud did) > > >> Until that happens, this sort of problem will recur infinitely because >> people will continue to miss or ignore CI failures because they send >> emails after merge/commit rather than before, and are formatted >> semi-incomprehensibly. >> >> Nate >> > > Regards, > Ben > > >> >> >> On 6/16/21 12:28 PM, Ben Cooksley wrote: >> > Hi all, >> > >> > The following is notice that I intend to withdraw CI services from the >> > following two KDE projects due to faults in their code or build system >> > which are having a significant adverse impact on the CI system and >> > negatively impacting on other projects: >> > >> > - KDevelop >> > - KDE Connect >> > >> > This withdrawal will be applied to all platforms. >> > >> > In the case of KDevelop, it has a series of unit tests which on FreeBSD >> > cause gdb to hang and consume an entire CPU core indefinitely. This >> > slows down builds for all other projects using that CI server, and also >> > prevents KWin tests from proceeding - completely blocking it's jobs. >> > This fault is in the debuggee_slow family of tests. >> > >> > As this issue has persisted for some time now despite being mentioned, >> I >> > require that the family of tests in question be disabled across all >> > platforms. >> > >> > In the case of KDE Connect, as part of it's configure process it runs >> an >> > external command that results in dbus-daemon being launched. This >> > process persists following the build and would only be cleaned up by >> our >> > tooling that runs tests. Should the compilation fail (as it does >> > currently) it will result in the CI builder being broken - which is why >> > we have had so many Windows builds fail lately. >> > >> > As this is an issue that has occurred previously, I require that the >> > configure time check which is launching dbus-daemon to be expunged from >> > KDE Connect. >> > >> > As a reminder to all projects, running commands that interact with >> > dbus-daemon or kdeinit is not permitted during configure or build time. >> > >> > Regards, >> > Ben Cooksley >> > KDE Sysadmin >> >
Re: Notice of withdrawal of CI services: KDevelop and KDE Connect
This kind of problem will be generically solved for everyone once we get GitLab's pre-commit CI, which can block merging of MRs until the failures are resolved--so they actually *will* be resolved. How soon can we get that finally rolled out across KDE? Until that happens, this sort of problem will recur infinitely because people will continue to miss or ignore CI failures because they send emails after merge/commit rather than before, and are formatted semi-incomprehensibly. Nate On 6/16/21 12:28 PM, Ben Cooksley wrote: Hi all, The following is notice that I intend to withdraw CI services from the following two KDE projects due to faults in their code or build system which are having a significant adverse impact on the CI system and negatively impacting on other projects: - KDevelop - KDE Connect This withdrawal will be applied to all platforms. In the case of KDevelop, it has a series of unit tests which on FreeBSD cause gdb to hang and consume an entire CPU core indefinitely. This slows down builds for all other projects using that CI server, and also prevents KWin tests from proceeding - completely blocking it's jobs. This fault is in the debuggee_slow family of tests. As this issue has persisted for some time now despite being mentioned, I require that the family of tests in question be disabled across all platforms. In the case of KDE Connect, as part of it's configure process it runs an external command that results in dbus-daemon being launched. This process persists following the build and would only be cleaned up by our tooling that runs tests. Should the compilation fail (as it does currently) it will result in the CI builder being broken - which is why we have had so many Windows builds fail lately. As this is an issue that has occurred previously, I require that the configure time check which is launching dbus-daemon to be expunged from KDE Connect. As a reminder to all projects, running commands that interact with dbus-daemon or kdeinit is not permitted during configure or build time. Regards, Ben Cooksley KDE Sysadmin
Re: Notice of withdrawal of CI services: KDevelop and KDE Connect
On Mittwoch, 16. Juni 2021 20:28:25 CEST Ben Cooksley wrote: > Hi all, > > The following is notice that I intend to withdraw CI services from the > following two KDE projects due to faults in their code or build system > which are having a significant adverse impact on the CI system and > negatively impacting on other projects: > > - KDevelop > - KDE Connect > > This withdrawal will be applied to all platforms. > > In the case of KDevelop, it has a series of unit tests which on FreeBSD > cause gdb to hang and consume an entire CPU core indefinitely. This slows > down builds for all other projects using that CI server, and also prevents > KWin tests from proceeding - completely blocking it's jobs. This fault is > in the debuggee_slow family of tests. Hey Ben, first time I hear of this issue. I simply don't have the capacity to track kdevelop CI mails, so if anything really bad happens, I would really appreciate if anyone who notices that sents a mail to the kdevelop mailing list so we can act on it. I still use kdevelop daily, but don't put any other work in it currently due to lack of time... That said: can we just disable it on the FreeBSD platform, if that's the only one that exhibits this failure? Alternatively I'm obviously fine with skipping that test on that platform, can you give me a link to a failure please so I can see which tests exactly are affected? Then I'll add the QSKIP + platform ifdef checks to skip it on freebsd. Cheers and thanks for letting me know about this problem -- Milian Wolff m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part.
Re: Notice of withdrawal of CI services: KDevelop and KDE Connect
On Mittwoch, 16. Juni 2021 20:28:25 CEST Ben Cooksley wrote: > Hi all, > > The following is notice that I intend to withdraw CI services from the > following two KDE projects due to faults in their code or build system > which are having a significant adverse impact on the CI system and > negatively impacting on other projects: > > - KDevelop > - KDE Connect > > This withdrawal will be applied to all platforms. > > In the case of KDevelop, it has a series of unit tests which on FreeBSD > cause gdb to hang and consume an entire CPU core indefinitely. This slows > down builds for all other projects using that CI server, and also prevents > KWin tests from proceeding - completely blocking it's jobs. This fault is > in the debuggee_slow family of tests. Hey Ben, first time I hear of this issue. I simply don't have the capacity to track kdevelop CI mails, so if anything really bad happens, I would really appreciate if anyone who notices that sents a mail to the kdevelop mailing list so we can act on it. I still use kdevelop daily, but don't put any other work in it currently due to lack of time... That said: can we just disable it on the FreeBSD platform, if that's the only one that exhibits this failure? Alternatively I'm obviously fine with skipping that test on that platform, can you give me a link to a failure please so I can see which tests exactly are affected? Then I'll add the QSKIP + platform ifdef checks to skip it on freebsd. Cheers and thanks for letting me know about this problem -- Milian Wolff m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part.
Re: Notice of withdrawal of CI services: KDevelop and KDE Connect
Hi Ben, On 16.06.21 20:28, Ben Cooksley wrote: Hi all, The following is notice that I intend to withdraw CI services from the following two KDE projects due to faults in their code or build system which are having a significant adverse impact on the CI system and negatively impacting on other projects: - KDevelop - KDE Connect This withdrawal will be applied to all platforms. In the case of KDevelop, it has a series of unit tests which on FreeBSD cause gdb to hang and consume an entire CPU core indefinitely. This slows down builds for all other projects using that CI server, and also prevents KWin tests from proceeding - completely blocking it's jobs. This fault is in the debuggee_slow family of tests. As this issue has persisted for some time now despite being mentioned, I require that the family of tests in question be disabled across all platforms. In the case of KDE Connect, as part of it's configure process it runs an external command that results in dbus-daemon being launched. This process persists following the build and would only be cleaned up by our tooling that runs tests. Should the compilation fail (as it does currently) it will result in the CI builder being broken - which is why we have had so many Windows builds fail lately. As this is an issue that has occurred previously, I require that the configure time check which is launching dbus-daemon to be expunged from KDE Connect. As a reminder to all projects, running commands that interact with dbus-daemon or kdeinit is not permitted during configure or build time. Regards, Ben Cooksley KDE Sysadmin I think I know what causes the KDE Connect behavior. The CMake code calls 'ecm_find_qmlmodule(org.kde.people 1.0)', which results a call to 'qmlplugindump org.kde.kpeople 1.0' which causes parts of the KPeople code to be executed (PersonsModel in particular) which does some DBus things that then trigger dbus-daemon. As a stopgap solution to make the CI operational we can remove that ecm_find_qmlmodule call. In terms of a proper solution there was a recent effort to remove the mandatory DBus dependency from KPeople on Windows (https://invent.kde.org/frameworks/kpeople/-/merge_requests/7). Perhaps we should instead fully disable all DBus code in KPeople on Windows instead, given that the usefulness is questionable. Cheers Nico
Re: Notice of withdrawal of CI services: KDevelop and KDE Connect
Hi Ben, On 16.06.21 20:28, Ben Cooksley wrote: Hi all, The following is notice that I intend to withdraw CI services from the following two KDE projects due to faults in their code or build system which are having a significant adverse impact on the CI system and negatively impacting on other projects: - KDevelop - KDE Connect This withdrawal will be applied to all platforms. In the case of KDevelop, it has a series of unit tests which on FreeBSD cause gdb to hang and consume an entire CPU core indefinitely. This slows down builds for all other projects using that CI server, and also prevents KWin tests from proceeding - completely blocking it's jobs. This fault is in the debuggee_slow family of tests. As this issue has persisted for some time now despite being mentioned, I require that the family of tests in question be disabled across all platforms. In the case of KDE Connect, as part of it's configure process it runs an external command that results in dbus-daemon being launched. This process persists following the build and would only be cleaned up by our tooling that runs tests. Should the compilation fail (as it does currently) it will result in the CI builder being broken - which is why we have had so many Windows builds fail lately. As this is an issue that has occurred previously, I require that the configure time check which is launching dbus-daemon to be expunged from KDE Connect. As a reminder to all projects, running commands that interact with dbus-daemon or kdeinit is not permitted during configure or build time. Regards, Ben Cooksley KDE Sysadmin I think I know what causes the KDE Connect behavior. The CMake code calls 'ecm_find_qmlmodule(org.kde.people 1.0)', which results a call to 'qmlplugindump org.kde.kpeople 1.0' which causes parts of the KPeople code to be executed (PersonsModel in particular) which does some DBus things that then trigger dbus-daemon. As a stopgap solution to make the CI operational we can remove that ecm_find_qmlmodule call. In terms of a proper solution there was a recent effort to remove the mandatory DBus dependency from KPeople on Windows (https://invent.kde.org/frameworks/kpeople/-/merge_requests/7). Perhaps we should instead fully disable all DBus code in KPeople on Windows instead, given that the usefulness is questionable. Cheers Nico
Re: Notice of withdrawal of CI services: KDevelop and KDE Connect
How about if we add a config flag for our ci machines and configure cmake of these 2 project's test to ignore building/adding those problematic tests whenever it saw those flags? I don't know why but it doesn't sound correct to me to kill the ci build of any project because of these types of problems. Ömer Fadıl Usta PGP key : 0xfd11561976b1690b about.me/omerusta Ben Cooksley , 16 Haz 2021 Çar, 21:57 tarihinde şunu yazdı: > On Thu, Jun 17, 2021 at 6:41 AM Nate Graham wrote: > >> This kind of problem will be generically solved for everyone once we get >> GitLab's pre-commit CI, which can block merging of MRs until the >> failures are resolved--so they actually *will* be resolved. How soon can >> we get that finally rolled out across KDE? >> > > I'm afraid GitLab CI wouldn't have prevented this from occurring - because > the pre-merge CI still needs to run somewhere. > The problem here is that the simple act of running the build > degrades/breaks the builders for everyone else. > > In terms of a timeline on this, once I have the situation with Nextcloud > sorted out (which had to be prioritised as the version we're on goes out of > support in the next few months) we'll hopefully be able to work on GitLab > CI (assuming another vendor of ours doesn't go and pull another major > dependency bump stunt like Nextcloud did) > > >> Until that happens, this sort of problem will recur infinitely because >> people will continue to miss or ignore CI failures because they send >> emails after merge/commit rather than before, and are formatted >> semi-incomprehensibly. >> >> Nate >> > > Regards, > Ben > > >> >> >> On 6/16/21 12:28 PM, Ben Cooksley wrote: >> > Hi all, >> > >> > The following is notice that I intend to withdraw CI services from the >> > following two KDE projects due to faults in their code or build system >> > which are having a significant adverse impact on the CI system and >> > negatively impacting on other projects: >> > >> > - KDevelop >> > - KDE Connect >> > >> > This withdrawal will be applied to all platforms. >> > >> > In the case of KDevelop, it has a series of unit tests which on FreeBSD >> > cause gdb to hang and consume an entire CPU core indefinitely. This >> > slows down builds for all other projects using that CI server, and also >> > prevents KWin tests from proceeding - completely blocking it's jobs. >> > This fault is in the debuggee_slow family of tests. >> > >> > As this issue has persisted for some time now despite being mentioned, >> I >> > require that the family of tests in question be disabled across all >> > platforms. >> > >> > In the case of KDE Connect, as part of it's configure process it runs >> an >> > external command that results in dbus-daemon being launched. This >> > process persists following the build and would only be cleaned up by >> our >> > tooling that runs tests. Should the compilation fail (as it does >> > currently) it will result in the CI builder being broken - which is why >> > we have had so many Windows builds fail lately. >> > >> > As this is an issue that has occurred previously, I require that the >> > configure time check which is launching dbus-daemon to be expunged from >> > KDE Connect. >> > >> > As a reminder to all projects, running commands that interact with >> > dbus-daemon or kdeinit is not permitted during configure or build time. >> > >> > Regards, >> > Ben Cooksley >> > KDE Sysadmin >> >
Re: Notice of withdrawal of CI services: KDevelop and KDE Connect
On Thu, Jun 17, 2021 at 6:41 AM Nate Graham wrote: > This kind of problem will be generically solved for everyone once we get > GitLab's pre-commit CI, which can block merging of MRs until the > failures are resolved--so they actually *will* be resolved. How soon can > we get that finally rolled out across KDE? > I'm afraid GitLab CI wouldn't have prevented this from occurring - because the pre-merge CI still needs to run somewhere. The problem here is that the simple act of running the build degrades/breaks the builders for everyone else. In terms of a timeline on this, once I have the situation with Nextcloud sorted out (which had to be prioritised as the version we're on goes out of support in the next few months) we'll hopefully be able to work on GitLab CI (assuming another vendor of ours doesn't go and pull another major dependency bump stunt like Nextcloud did) > Until that happens, this sort of problem will recur infinitely because > people will continue to miss or ignore CI failures because they send > emails after merge/commit rather than before, and are formatted > semi-incomprehensibly. > > Nate > Regards, Ben > > > On 6/16/21 12:28 PM, Ben Cooksley wrote: > > Hi all, > > > > The following is notice that I intend to withdraw CI services from the > > following two KDE projects due to faults in their code or build system > > which are having a significant adverse impact on the CI system and > > negatively impacting on other projects: > > > > - KDevelop > > - KDE Connect > > > > This withdrawal will be applied to all platforms. > > > > In the case of KDevelop, it has a series of unit tests which on FreeBSD > > cause gdb to hang and consume an entire CPU core indefinitely. This > > slows down builds for all other projects using that CI server, and also > > prevents KWin tests from proceeding - completely blocking it's jobs. > > This fault is in the debuggee_slow family of tests. > > > > As this issue has persisted for some time now despite being mentioned, I > > require that the family of tests in question be disabled across all > > platforms. > > > > In the case of KDE Connect, as part of it's configure process it runs an > > external command that results in dbus-daemon being launched. This > > process persists following the build and would only be cleaned up by our > > tooling that runs tests. Should the compilation fail (as it does > > currently) it will result in the CI builder being broken - which is why > > we have had so many Windows builds fail lately. > > > > As this is an issue that has occurred previously, I require that the > > configure time check which is launching dbus-daemon to be expunged from > > KDE Connect. > > > > As a reminder to all projects, running commands that interact with > > dbus-daemon or kdeinit is not permitted during configure or build time. > > > > Regards, > > Ben Cooksley > > KDE Sysadmin >
Re: Notice of withdrawal of CI services: KDevelop and KDE Connect
On Thu, Jun 17, 2021 at 6:41 AM Nate Graham wrote: > This kind of problem will be generically solved for everyone once we get > GitLab's pre-commit CI, which can block merging of MRs until the > failures are resolved--so they actually *will* be resolved. How soon can > we get that finally rolled out across KDE? > I'm afraid GitLab CI wouldn't have prevented this from occurring - because the pre-merge CI still needs to run somewhere. The problem here is that the simple act of running the build degrades/breaks the builders for everyone else. In terms of a timeline on this, once I have the situation with Nextcloud sorted out (which had to be prioritised as the version we're on goes out of support in the next few months) we'll hopefully be able to work on GitLab CI (assuming another vendor of ours doesn't go and pull another major dependency bump stunt like Nextcloud did) > Until that happens, this sort of problem will recur infinitely because > people will continue to miss or ignore CI failures because they send > emails after merge/commit rather than before, and are formatted > semi-incomprehensibly. > > Nate > Regards, Ben > > > On 6/16/21 12:28 PM, Ben Cooksley wrote: > > Hi all, > > > > The following is notice that I intend to withdraw CI services from the > > following two KDE projects due to faults in their code or build system > > which are having a significant adverse impact on the CI system and > > negatively impacting on other projects: > > > > - KDevelop > > - KDE Connect > > > > This withdrawal will be applied to all platforms. > > > > In the case of KDevelop, it has a series of unit tests which on FreeBSD > > cause gdb to hang and consume an entire CPU core indefinitely. This > > slows down builds for all other projects using that CI server, and also > > prevents KWin tests from proceeding - completely blocking it's jobs. > > This fault is in the debuggee_slow family of tests. > > > > As this issue has persisted for some time now despite being mentioned, I > > require that the family of tests in question be disabled across all > > platforms. > > > > In the case of KDE Connect, as part of it's configure process it runs an > > external command that results in dbus-daemon being launched. This > > process persists following the build and would only be cleaned up by our > > tooling that runs tests. Should the compilation fail (as it does > > currently) it will result in the CI builder being broken - which is why > > we have had so many Windows builds fail lately. > > > > As this is an issue that has occurred previously, I require that the > > configure time check which is launching dbus-daemon to be expunged from > > KDE Connect. > > > > As a reminder to all projects, running commands that interact with > > dbus-daemon or kdeinit is not permitted during configure or build time. > > > > Regards, > > Ben Cooksley > > KDE Sysadmin >
Re: Notice of withdrawal of CI services: KDevelop and KDE Connect
This kind of problem will be generically solved for everyone once we get GitLab's pre-commit CI, which can block merging of MRs until the failures are resolved--so they actually *will* be resolved. How soon can we get that finally rolled out across KDE? Until that happens, this sort of problem will recur infinitely because people will continue to miss or ignore CI failures because they send emails after merge/commit rather than before, and are formatted semi-incomprehensibly. Nate On 6/16/21 12:28 PM, Ben Cooksley wrote: Hi all, The following is notice that I intend to withdraw CI services from the following two KDE projects due to faults in their code or build system which are having a significant adverse impact on the CI system and negatively impacting on other projects: - KDevelop - KDE Connect This withdrawal will be applied to all platforms. In the case of KDevelop, it has a series of unit tests which on FreeBSD cause gdb to hang and consume an entire CPU core indefinitely. This slows down builds for all other projects using that CI server, and also prevents KWin tests from proceeding - completely blocking it's jobs. This fault is in the debuggee_slow family of tests. As this issue has persisted for some time now despite being mentioned, I require that the family of tests in question be disabled across all platforms. In the case of KDE Connect, as part of it's configure process it runs an external command that results in dbus-daemon being launched. This process persists following the build and would only be cleaned up by our tooling that runs tests. Should the compilation fail (as it does currently) it will result in the CI builder being broken - which is why we have had so many Windows builds fail lately. As this is an issue that has occurred previously, I require that the configure time check which is launching dbus-daemon to be expunged from KDE Connect. As a reminder to all projects, running commands that interact with dbus-daemon or kdeinit is not permitted during configure or build time. Regards, Ben Cooksley KDE Sysadmin
Notice of withdrawal of CI services: KDevelop and KDE Connect
Hi all, The following is notice that I intend to withdraw CI services from the following two KDE projects due to faults in their code or build system which are having a significant adverse impact on the CI system and negatively impacting on other projects: - KDevelop - KDE Connect This withdrawal will be applied to all platforms. In the case of KDevelop, it has a series of unit tests which on FreeBSD cause gdb to hang and consume an entire CPU core indefinitely. This slows down builds for all other projects using that CI server, and also prevents KWin tests from proceeding - completely blocking it's jobs. This fault is in the debuggee_slow family of tests. As this issue has persisted for some time now despite being mentioned, I require that the family of tests in question be disabled across all platforms. In the case of KDE Connect, as part of it's configure process it runs an external command that results in dbus-daemon being launched. This process persists following the build and would only be cleaned up by our tooling that runs tests. Should the compilation fail (as it does currently) it will result in the CI builder being broken - which is why we have had so many Windows builds fail lately. As this is an issue that has occurred previously, I require that the configure time check which is launching dbus-daemon to be expunged from KDE Connect. As a reminder to all projects, running commands that interact with dbus-daemon or kdeinit is not permitted during configure or build time. Regards, Ben Cooksley KDE Sysadmin
Notice of withdrawal of CI services: KDevelop and KDE Connect
Hi all, The following is notice that I intend to withdraw CI services from the following two KDE projects due to faults in their code or build system which are having a significant adverse impact on the CI system and negatively impacting on other projects: - KDevelop - KDE Connect This withdrawal will be applied to all platforms. In the case of KDevelop, it has a series of unit tests which on FreeBSD cause gdb to hang and consume an entire CPU core indefinitely. This slows down builds for all other projects using that CI server, and also prevents KWin tests from proceeding - completely blocking it's jobs. This fault is in the debuggee_slow family of tests. As this issue has persisted for some time now despite being mentioned, I require that the family of tests in question be disabled across all platforms. In the case of KDE Connect, as part of it's configure process it runs an external command that results in dbus-daemon being launched. This process persists following the build and would only be cleaned up by our tooling that runs tests. Should the compilation fail (as it does currently) it will result in the CI builder being broken - which is why we have had so many Windows builds fail lately. As this is an issue that has occurred previously, I require that the configure time check which is launching dbus-daemon to be expunged from KDE Connect. As a reminder to all projects, running commands that interact with dbus-daemon or kdeinit is not permitted during configure or build time. Regards, Ben Cooksley KDE Sysadmin
