On Sat, 2024-02-24 at 22:16 +1300, Ben Cooksley wrote: > On Sat, Feb 24, 2024 at 8:37 PM Konstantin Kharlamov > <hi-an...@yandex.ru> wrote: > > On Sat, 2024-02-24 at 16:31 +1300, Ben Cooksley wrote: > > > On Fri, Feb 23, 2024 at 11:12 PM Sune Vuorela <nos...@vuorela.dk> > > > wrote: > > > > On 2024-02-22, Nate Graham <n...@kde.org> wrote: > > > > > I've started pondering post-megarelease projects. We've spent > > > > so long on > > > > > porting and bugfixing that I think it might be useful to > > > > shift gears to > > > > > feature work, and I'd like to brainstorm potential large- > > > > scale projects > > > > > and gauge the level of interest in putting resources into > > > > them soon. > > > > > > > > A bit more from the devops end that I'd love to see people > > > > tackle: > > > > > > > > - Ensure frameworks and app unit tests interacting with > > > > windows can run > > > > on Windows. > > > > More details: The following fails on our windows CI > > > > > > > > https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp > > > > I find it weird that we are spending resources on putting > > > > things in > > > > the windows store and making apps available on windows, but > > > > we can't > > > > actually have passing tests in our CI. > > > > > > > > > > > > > This unfortunately will not be easy to solve. > > > > > > One of the key things that we've learned out of doing CI, as has > > > been showcased by FreeBSD in particular, is that the builders > > > need to be ephemeral - that is only around for the build in > > > question that is being run. > > > We're currently accomplishing this by using containers - via > > > Podman (for Linux/Android/FreeBSD) and Docker (for Windows). > > > > > > Containers also offer us the advantage of allowing people to > > > easily reproduce the CI environment on their local system without > > > too much trouble. > > > > > > For Windows however, Microsoft has limited the container stack to > > > not allow anything GUI related to work. The underlying libraries > > > may be there, but the equivalent display server components are > > > not operational. > > > > > > To complicate things further, on Windows certain permissions are > > > restricted to the interactive console and are not possible to do > > > as either a scheduled task or as a system service. > > > Usage of existing Windows automation frameworks such as > > > Powershell Remoting or SSH will therefore not work if we want > > > things to perfectly replicate a end user environment - because > > > those will run the command(s) as part of a non-interactive > > > session (even if the user we connect as is the same one logged in > > > on the desktop console). > > > > > > Idk if it's a silly question, but… If Windows native containers > > have so many restrictions, why not just use Linux containers with > > WINE inside? > > > > > Because Wine is not Windows either, and there could be subtle > differences in how things run / interact with the system. > Plus some of our software would like to test certain system level > infrastructure (like say KDE Connect).
Out of curiosity, what does this infrastructure include? I thought KDE connect only uses network sockets and system tray. > Plus, we have to have native Windows to compile things anyway as we > need to use MSVC (otherwise you have no Qt Web Engine support, as > that cannot be built with MingW) But I presume it can be built with Clang? In particular, Google Chrome on Windows is being built with Clang — and Web Engine is basically a fork of Chromium. > (and you cannot really mix MingW / MSVC binaries due to incompatible > compiler ABIs for C++ code) Well, if for testing purposes Qt was pre-built with Clang, I guess there won't be any ABI issues.