KDE Gear projects with failing CI (master) (21 May 2024)

[Ben Cooksley]

On Sun, May 26, 2024 at 6:59 PM Volker Krause <vkrause at 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 <vkrause at 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 <vkrause at 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 <aacid at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20240526/d4c8ee2d/attachment-0001.htm>