Unusual behaviour in KDE Connect CMake
Hi all, Recently changes were made to kdeconnect-kde that introduced new dependencies that broke the build on Windows. While this in itself is an issue, it has exposed a much more significant issue which requires urgent remediation as it breaks any Windows build node that attempts to carry out a build of kdeconnect. These breakages require manual Sysadmin intervention to correct. After diagnosing the issue, it would appear that kdeconnect-kde contains CMake code that results in "dbus-daemon.exe" being launched. While this may appear innocuous, it is problematic on Windows as it prevents the build workspace being wiped and then reused by later jobs. This was the cause of CI failures for various Frameworks, Dolphin and KDevelop. Prior to the new dependency being introduced this was not an issue, as the post-testing cleanup phase ensures that all KDE related processes (kdeinit5, kiod, kioslave, dbus-daemon, etc) are all terminated. As this creates persistent issues for other projects and because a new dependency was introduced without notification, the following is notice that Windows CI support for kdeconnect-kde will be terminated in 12 hours time should steps to resolve this not be taken. Regards, Ben Cooksley KDE Sysadmin
Re: Unusual behaviour in KDE Connect CMake
I'll get right on it On Wed, 7 Apr, 2021, 3:02 pm Ben Cooksley, wrote: > Hi all, > > Recently changes were made to kdeconnect-kde that introduced new > dependencies that broke the build on Windows. > > While this in itself is an issue, it has exposed a much more significant > issue which requires urgent remediation as it breaks any Windows build node > that attempts to carry out a build of kdeconnect. These breakages require > manual Sysadmin intervention to correct. > > After diagnosing the issue, it would appear that kdeconnect-kde contains > CMake code that results in "dbus-daemon.exe" being launched. While this may > appear innocuous, it is problematic on Windows as it prevents the build > workspace being wiped and then reused by later jobs. > > This was the cause of CI failures for various Frameworks, Dolphin and > KDevelop. > > Prior to the new dependency being introduced this was not an issue, as the > post-testing cleanup phase ensures that all KDE related processes > (kdeinit5, kiod, kioslave, dbus-daemon, etc) are all terminated. > > As this creates persistent issues for other projects and because a new > dependency was introduced without notification, the following is notice > that Windows CI support for kdeconnect-kde will be terminated in 12 hours > time should steps to resolve this not be taken. > > Regards, > Ben Cooksley > KDE Sysadmin >
Re: Unusual behaviour in KDE Connect CMake
On Wed, Apr 7, 2021 at 3:04 PM Piyush Aggarwal wrote: > I'll get right on it > > On Wed, 7 Apr, 2021, 3:02 pm Ben Cooksley, wrote: > >> Hi all, >> >> Recently changes were made to kdeconnect-kde that introduced new >> dependencies that broke the build on Windows. >> > This should be fixed by the https://invent.kde.org/network/kdeconnect-kde/-/commit/80178b8ff80c1e42692b309880d6f1435c62ce4e . Please poke the CI once so I can be sure. >> While this in itself is an issue, it has exposed a much more significant >> issue which requires urgent remediation as it breaks any Windows build node >> that attempts to carry out a build of kdeconnect. These breakages require >> manual Sysadmin intervention to correct. >> > This issue needs to be fixed appropriately. I wrote a way to kill dbus-daemon.exe with Win APIs in the kdeconnect-kde source, used here: https://github.com/KDE/kdeconnect-kde/blob/master/indicator/main.cpp#L106 . The Function's definition is here: https://github.com/KDE/kdeconnect-kde/blob/master/indicator/indicatorhelper_win.cpp#L48 . Please let me know if I can be of help and integrate it somewhere in Craft/ the CI. As this creates persistent issues for other projects and because a new >> dependency was introduced without notification, the following is notice >> that Windows CI support for kdeconnect-kde will be terminated in 12 hours >> time should steps to resolve this not be taken. >> > I apologize for the mishap and the inconvenience caused to the other projects. This was not intended. Best Piyush Aggarwal from the KDE Connect Team
Re: Unusual behaviour in KDE Connect CMake
On Wed, Apr 7, 2021 at 11:50 PM Piyush Aggarwal wrote: > > > On Wed, Apr 7, 2021 at 3:04 PM Piyush Aggarwal < > piyushaggarwal...@gmail.com> wrote: > >> I'll get right on it >> >> On Wed, 7 Apr, 2021, 3:02 pm Ben Cooksley, wrote: >> >>> Hi all, >>> >>> Recently changes were made to kdeconnect-kde that introduced new >>> dependencies that broke the build on Windows. >>> >> > This should be fixed by the > https://invent.kde.org/network/kdeconnect-kde/-/commit/80178b8ff80c1e42692b309880d6f1435c62ce4e > . Please poke the CI once so I can be sure. > Thanks. I've taken a look and it appears that it has corrected the build failure - which means we are now in the same situation as earlier, where the testing phase cleans up the dbus-daemon processes that are launched by the CMake configure phase (which stops it from breaking the node entirely, but is still not perfect) > > >>> While this in itself is an issue, it has exposed a much more significant >>> issue which requires urgent remediation as it breaks any Windows build node >>> that attempts to carry out a build of kdeconnect. These breakages require >>> manual Sysadmin intervention to correct. >>> >> > This issue needs to be fixed appropriately. I wrote a way to kill > dbus-daemon.exe with Win APIs in the kdeconnect-kde source, used here: > https://github.com/KDE/kdeconnect-kde/blob/master/indicator/main.cpp#L106 > . The Function's definition is here: > https://github.com/KDE/kdeconnect-kde/blob/master/indicator/indicatorhelper_win.cpp#L48 > . Please let me know if I can be of help and integrate it somewhere in > Craft/ the CI. > The C++ code is completely innocent in this case, one of the checks being run by CMake as part of the configure-time step is the cause of this issue. Do you have any kdeconnect-kde specific checks in there that call custom binaries / code to search for specific dependencies by any chance? > > As this creates persistent issues for other projects and because a new >>> dependency was introduced without notification, the following is notice >>> that Windows CI support for kdeconnect-kde will be terminated in 12 hours >>> time should steps to resolve this not be taken. >>> >> > I apologize for the mishap and the inconvenience caused to the other > projects. This was not intended. > > Best > Piyush Aggarwal > from the KDE Connect Team > > Thanks, Ben
Incubating linux-stopmotion
Dear KDE team, I would like to apply for linux-stopmotion to become a KDE project. == Project description == Linux Stopmotion is a Free Open Source application to create stop-motion animations. It helps you capture and edit the frames of your animation and export them as a single file. Direct capture from webcams, MiniDV cameras, and DSLR cameras. It offers onion-skinning, import images from disk, and time lapse photography. LSM supports multiple scenes, frame editing, basic sound track, animation playback at different frame rates, and GIMP integration for image. Movies can be exported to a file and to Cinelerra frame lists. Technically, it is a C++ / Qt application with optional dependencies to camera capture libraries. LSM is part of DebianEdu; LSM packages are available for at least Debian and openSuse. Website: linuxstopmotion.org Git / Mailing list: sourceforge.net/projects/linuxstopmotion/ == List of people committing to the project == Tim Band Christoph Grüninger == Plan to be in compliance with the KDE manifesto == We already comply wih the KDE manifesto - except for the infrastructure. We plan to - move over to KDE's Git repository - switch to a mailing list within KDE's infrastructure - use KDE bug tracker - see what else makes sense for the project like Phabricator Maybe we have to change the name of the application. Kind regards, Christoph
