[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Re: Post-MegaRelease projects
From: Konstantin Kharlamov <Hi-Angel () yandex ! ru>
Date: 2024-02-24 10:35:01
Message-ID: 463f65b5ecde8f3b70dc0f0edf8c902886a6f418.camel () yandex ! ru
[Download RAW message or body]
On Sat, 2024-02-24 at 23:07 +1300, Ben Cooksley wrote:
> On Sat, Feb 24, 2024 at 10:27 PM Konstantin Kharlamov
> <Hi-Angel@yandex.ru> wrote:
> > On Sat, 2024-02-24 at 22:16 +1300, Ben Cooksley wrote:
> > > On Sat, Feb 24, 2024 at 8:37 PM Konstantin Kharlamov
> > > <Hi-Angel@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
> > > > > <nospam@vuorela.dk> wrote:
> > > > > > On 2024-02-22, Nate Graham <nate@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.
Fair point, no sw is bugless. Although, from my shallow experience WINE
seems to have an excellent test suite. I remember reporting a
regression once, which turned out to be due to some obscure surfaces
manipulation by an old Heroes Ⅲ game. WINE devs not only quickly fixed
that, but they also added tests for that case, so I'd presume such
regression is just not gonna happen anymore.
> > > 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.
> >
>
>
> No idea, I saw their commentary on debugging issues they were having
> in their unit tests in #kde-devel.
> Those issues were due to a lack of permissions, specifically around
> the interactive console - that is how I know some of our tests need
> those additional permissions and why running as a scheduled task /
> system service will not be sufficient for "fully working" CI tests on
> Windows.
Sorry, it seems there's some misunderstanding… Judging by what you say
you seem to be referring to the restrictions that Windows containers
have on Windows. But that was the point that started this thread, to
which I replied that running Linux containers with WINE might be a
solution 😊
> > > 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.
> >
>
>
> Qt 6 as a whole does not list Clang as a supported compiler -
> see https://doc.qt.io/qt-6/supported-platforms.html
>
> Given Windows is a bit strange in the first place, i'd be quite
> reluctant to step outside of what they list as supported.
Oh, that's interesting. So Qt claims to support MinGW, but then
WebEngine does not actually build with it? So it's a bug on their side,
was it reported?
While at it, just to make sure I understand: do you compile with MSVC
everything or just the WebEngine (which Idk if it's possible without
the deps, but I guess asking doesn't hurt).
[Attachment #3 (text/html)]
<html><head><style>pre,code,address {
margin: 0px;
}
h1,h2,h3,h4,h5,h6 {
margin-top: 0.2em;
margin-bottom: 0.2em;
}
ol,ul {
margin-top: 0em;
margin-bottom: 0em;
}
blockquote {
margin-top: 0em;
margin-bottom: 0em;
}
</style></head><body><div>On Sat, 2024-02-24 at 23:07 +1300, Ben Cooksley \
wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf \
solid;padding-left:1ex"><div dir="ltr"><div dir="ltr">On Sat, Feb 24, 2024 at \
10:27 PM Konstantin Kharlamov <<a \
href="mailto:Hi-Angel@yandex.ru">Hi-Angel@yandex.ru</a>> wrote:<br></div><div \
class="gmail_quote"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px \
#729fcf solid;padding-left:1ex"><div class="msg6562826726821868836"><div><div>On Sat, \
2024-02-24 at 22:16 +1300, Ben Cooksley wrote:</div><blockquote type="cite" \
style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div \
dir="ltr"><div dir="ltr">On Sat, Feb 24, 2024 at 8:37 PM Konstantin Kharlamov \
<<a href="mailto:Hi-Angel@yandex.ru" target="_blank">Hi-Angel@yandex.ru</a>> \
wrote:<br></div><div class="gmail_quote"><blockquote type="cite" style="margin:0 0 0 \
.8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><div><div>On Sat, \
2024-02-24 at 16:31 +1300, Ben Cooksley wrote:</div><blockquote type="cite" \
style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div \
dir="ltr"><div dir="ltr">On Fri, Feb 23, 2024 at 11:12 PM Sune Vuorela <<a \
href="mailto:nospam@vuorela.dk" target="_blank">nospam@vuorela.dk</a>> \
wrote:<br></div><div class="gmail_quote"><blockquote type="cite" style="margin:0 0 0 \
.8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>On 2024-02-22, Nate Graham \
<<a href="mailto:nate@kde.org" target="_blank">nate@kde.org</a>> wrote:<br>> \
I've started pondering post-megarelease projects. We've spent so long on <br>> \
porting and bugfixing that I think it might be useful to shift gears to <br>> \
feature work, and I'd like to brainstorm potential large-scale projects <br>> and \
gauge the level of interest in putting resources into them soon.<br></div><div><br>A \
bit more from the devops end that I'd love to see people \
tackle:<br></div><div><br> - Ensure frameworks and app unit tests interacting \
with windows can run<br> on Windows.<br> More details: The \
following fails on our windows CI<br> <a \
href="https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp" \
rel="noreferrer" target="_blank">https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp</a><br> \
I find it weird that we are spending resources on putting things in<br> \
the windows store and making apps available on windows, but we can't<br> \
actually have passing tests in our \
CI.<br></div><div><br></div></blockquote><div><br></div><div>This unfortunately will \
not be easy to solve. </div><div><br></div><div>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.</div><div>We're currently accomplishing this by using containers - \
via Podman (for Linux/Android/FreeBSD) and Docker (for \
Windows).<br></div><div><br></div><div>Containers also offer us the advantage of \
allowing people to easily reproduce the CI environment on their local system without \
too much trouble.</div><div><br></div><div>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.</div><div><div><br></div><div>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.</div><div><div>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).</div></div></div></div></div></blockquote><div><br></div><div>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?</div></div></div><div><br></div></blockquote><div><br></div><div>Because Wine \
is not Windows either, and there could be subtle differences in how things run / \
interact with the system.</div></div></div></blockquote></div></div></blockquote></div></div></blockquote><div><br></div><div>Fair \
point, no sw is bugless. Although, from my shallow experience WINE seems to have an \
excellent test suite. I remember reporting a regression once, which turned out to be \
due to some obscure surfaces manipulation by an old Heroes Ⅲ game. WINE devs not \
only quickly fixed that, but they also added tests for that case, so I'd presume such \
regression is just not gonna happen anymore.</div><div><br></div><blockquote \
type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf \
solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote \
type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf \
solid;padding-left:1ex"><div class="msg6562826726821868836"><div><blockquote \
type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf \
solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Plus some of our \
software would like to test certain system level infrastructure (like say KDE \
Connect).</div></div></div></blockquote><div><br></div><div>Out of curiosity, what \
does this infrastructure include? I thought KDE connect only uses network sockets and \
system tray.</div></div></div><br></blockquote><div><br></div><div>No idea, I saw \
their commentary on debugging issues they were having in their unit tests in \
#kde-devel.</div><div>Those issues were due to a lack of permissions, specifically \
around the interactive console - that is how I know some of our tests need those \
additional permissions and why running as a scheduled task / system service will not \
be sufficient for "fully working" CI tests on \
Windows.</div></div></div></blockquote><div><br></div><div>Sorry, it seems there's \
some misunderstanding… Judging by what you say you seem to be referring to the \
restrictions that Windows containers have on Windows. But that was the point that \
started this thread, to which I replied that running Linux containers with WINE might \
be a solution 😊</div><div><br></div><blockquote type="cite" style="margin:0 0 0 \
.8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr"><div \
class="gmail_quote"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px \
#729fcf solid;padding-left:1ex"><div class="msg6562826726821868836"><div><blockquote \
type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf \
solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>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)</div></div></div></blockquote><div><br></div><div>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.</div></div></div><br></blockquote><div><br></div><div>Qt 6 as a whole does \
not list Clang as a supported compiler - see <a \
href="https://doc.qt.io/qt-6/supported-platforms.html">https://doc.qt.io/qt-6/supported-platforms.html</a></div><div><br></div><div>Given \
Windows is a bit strange in the first place, i'd be quite reluctant to step outside \
of what they list as supported.</div></div></div></blockquote><div><br></div><div>Oh, \
that's interesting. So Qt claims to support MinGW, but then WebEngine does not \
actually build with it? So it's a bug on their side, was it \
reported?</div><div><br></div><div>While at it, just to make sure I understand: do \
you compile with MSVC everything or just the WebEngine (which Idk if it's possible \
without the deps, but I guess asking doesn't \
hurt).</div><div><span></span></div></body></html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic