On Donnerstag, 17. Juni 2021 11:25:15 CEST Ben Cooksley wrote: > On Thu, Jun 17, 2021 at 8:44 AM Milian Wolff <m...@milianw.de> 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). > > jenkins 60635 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) > jenkins 74167 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.