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