<div dir="ltr"><div dir="ltr">On Sun, May 26, 2024 at 6:59 PM Volker Krause <<a href="mailto:vkrause@kde.org">vkrause@kde.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Samstag, 25. Mai 2024 13:34:53 CEST Ben Cooksley wrote:<br>
> On Sat, May 25, 2024 at 3:09 AM Volker Krause <<a href="mailto:vkrause@kde.org" target="_blank">vkrause@kde.org</a>> wrote:<br>
> > On Freitag, 24. Mai 2024 12:24:16 CEST Ben Cooksley wrote:<br>
> > > On Fri, May 24, 2024 at 4:13 AM Volker Krause <<a href="mailto:vkrause@kde.org" target="_blank">vkrause@kde.org</a>> wrote:<br>
> > > > On Mittwoch, 22. Mai 2024 10:27:07 CEST Ben Cooksley wrote:<br>
> > > > > On Wed, May 22, 2024 at 9:24 AM Albert Astals Cid <<a href="mailto:aacid@kde.org" target="_blank">aacid@kde.org</a>><br>
> > <br>
> > wrote:<br>
> > > > > > Please work on fixing them, otherwise i will remove the failing CI<br>
> > > > <br>
> > > > jobs on<br>
> > > > <br>
> > > > > > their 4th failing week, it is very important that CI is passing<br>
> > > > > > for<br>
> > > > > > multiple<br>
> > > > > > reasons.<br>
> > > > > > <br>
> > > > > > Good news: 8 repositories fixed<br>
> > > > > > <br>
> > > > > > Bad news: 6 new repositories started failing<br>
> > > > > > <br>
> > > > > > <br>
> > > > > > kio-gdrive - NEW<br>
> > > > > > <br>
> > > > > >  * <a href="https://invent.kde.org/network/kio-gdrive/-/pipelines/693840" rel="noreferrer" target="_blank">https://invent.kde.org/network/kio-gdrive/-/pipelines/693840</a><br>
> > > > > >  <br>
> > > > > >   * Qt 5.15 is unbuildable because needs libkgapi and we don't<br>
> > <br>
> > have a<br>
> > <br>
> > > > Qt5<br>
> > > > <br>
> > > > > > CI<br>
> > > > > > build of libkgapi anymore. This is REAL BAD.<br>
> > > > > <br>
> > > > > Looks like kio-gdrive needs to drop the support it has for Qt 5?<br>
> > > > > Can't really see another path forward as libkgapi has no support for<br>
> > <br>
> > Qt<br>
> > <br>
> > > > > 5<br>
> > > > > anymore.<br>
> > > > > <br>
> > > > > This is alas one of those very difficult to solve issues, especially<br>
> > > > > when<br>
> > > > > semi-leaf projects like libkgapi are used more widely.<br>
> > > > <br>
> > > > Would it work to have a kf5 branch rule for libkgapi pointing to the<br>
> > <br>
> > last<br>
> > <br>
> > > > branch with Qt 5 support (and similar for all its dependencies)?<br>
> > > <br>
> > > Unfortunately not possible i'm afraid - as release/23.08 is no longer<br>
> > > supported (as no further releases are being made).<br>
> > > I therefore terminated all CI support for that branch to ensure that any<br>
> > > issues like this one were forced to the surface.<br>
> > <br>
> > But do we actually need CI for libkgapi for this? We only need it<br>
> > available as<br>
> > a dependency, so theoretically even distro packages in the CI image would<br>
> > work<br>
> > (I'm very reluctant to try that though, as that might have all kinds of<br>
> > surprising side-effects due to whatever else that might pull in (e.g.<br>
> > ECM)).<br>
> > Therefore the idea to let the seed job provide it, by means of a kf5<br>
> > branch<br>
> > rule.<br>
> <br>
> Distribution packages definitely won't work :)<br>
> <br>
> Unfortunately the seed jobs can't help here, as the entirety of<br>
> release/23.08 has been dropped from the CI system.<br>
> There are also rules in place to continually re-drop any release/23.08<br>
> packages that do appear in the system.<br>
<br>
ah, so the problem isn't that the seed job wouldn't be able to build this, but <br>
the result wont be persisted?<br></blockquote><div><br></div><div>Correct. That is assuming that libkgapi doesn't have any other dependencies within KDE Gear of course.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Next idea: add a kf5 branch to libkgapi, pointing to the latest release/23.08 <br>
state, and change the branch rules accordingly. We did that for a few non-<br>
branched repos during the transition period of their (branched) consumers IIRC <br>
(e.g. kweathercore, kirigami-addons).<br></blockquote><div><br></div><div>This would work totally fine. </div><div>For distributions, do we have any kind of release plan for this as they will need this in order to be able to build kio-gdrive?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> > > The dependency chain is also @same as both are part of KDE Gear so from<br>
> > > a<br>
> > > technical perspective that doesn't work either.<br>
> > <br>
> > It's @stable and @latest-kf6 depending on the Qt version in kio-gdrive,<br>
> > and<br>
> > inside libkgapi it's @latest for its KF5 dependencies, which seems correct<br>
> > IIUC?<br>
> <br>
> @stable for the relationship between libkgapi and kio-gdrive isn't correct<br>
> as they're both within KDE Gear no?<br>
<br>
In general, yes. But practically libkgapi isn't in Gear anymore from a Qt5 <br>
kio-gdrive perspective, so pointing to a specific (older) branch instead would <br>
seem like something that could help here.<br>
<br>
> > > From a practical perspective, i'm not sure you can really release<br>
> > <br>
> > something<br>
> > <br>
> > > as part of a bundle that needs something from an older release of that<br>
> > <br>
> > same<br>
> > <br>
> > > bundle in order to build...<br>
> > <br>
> > We already have that mixed scenario anyway in 24.02 it seems, so that is<br>
> > apparently working.<br>
> <br>
> I'm only aware of one case where that happened, which was a special one off<br>
> as KF5 apps needed the Qt 5 plugins still?<br>
> (I think this was kio-extras)<br>
<br>
Yeah, KIO workers is one such case. There's also some inter-dependencies in <br>
edu that are not a problem yet but where different parts seem to be moving at <br>
different speeds towards Qt 6 (Labplot <-> Cantor, Marble <-> *). Hopefully <br>
none of that becomes a problem, but I'd feel better if we have less drastic <br>
options available to deal with that :)<br></blockquote><div><br></div><div>Yes, those have already started to poke through here and there.</div><div>(Labplot/Cantor most notably, haven't seen any Marble issues yet)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> Perhaps we need to ask distributions to treat kio-gdrive the same?<br>
> <br>
> > > The only fix is to either drop Qt 5 support from kio-gdrive, or to<br>
> > <br>
> > restore<br>
> > <br>
> > > Qt 5 support to libkgapi.<br>
> > <br>
> > Don't get me wrong, I'm all for retiring Qt5 stuff as soon as we can, but<br>
> > I<br>
> > fear this isn't the only place where we will hit this problem, and not all<br>
> > of<br>
> > those might be able to do that just yet.<br>
> <br>
> In an ideal world, applications (the leaves) would drop Qt 5 support first,<br>
> and then once all consumers had migrated away the libraries would start<br>
> dropping support.<br>
> Not sure why libkgapi had to rush to drop Qt 5....<br>
<br>
My guess is this was mainly a matter of not being aware of kio-gdrive using <br>
this and only considering kdepim-runtime for the decision.<br></blockquote><div><br></div><div>Perhaps we need to move libkgapi to libraries/ instead of leaving it within pim/ given the fact that it is used outside of PIM?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Regards,<br>
Volker</blockquote><div><br></div><div>Cheers,</div><div>Ben </div></div></div>