KDE Gear projects with failing CI (master) (21 May 2024)
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. massif-visualizer - NEW * https://invent.kde.org/sdk/massif-visualizer/-/pipelines/693832 * appstreamtest fails because https://apps.kde.org/massif-visualizer doesn't exist baloo-widgets - NEW * https://invent.kde.org/libraries/baloo-widgets/-/pipelines/693837 * filemetadataitemcounttest failed in Linux Qt 6.7 tokodon - NEW * https://invent.kde.org/network/tokodon/-/pipelines/693844 * TimelineTest failed in Linux Qt 6.7 okular - NEW * https://invent.kde.org/graphics/okular/-/pipelines/693821 * craft mac and windows failed, possibly in codesign? kdenlive - NEW * https://invent.kde.org/multimedia/kdenlive/-/pipelines/693822 * craft windows failed, possibly in codesign? * craft mac has been stuck for hours, builder down? Cheers, Albert
Re: KDE Gear projects with failing CI (master) (21 May 2024)
Am Dienstag, 21. Mai 2024, 23:23:53 MESZ schrieb Albert Astals Cid: > massif-visualizer - NEW > * https://invent.kde.org/sdk/massif-visualizer/-/pipelines/693832 > * appstreamtest fails because https://apps.kde.org/massif-visualizer > doesn't exist Meh. apps.kde.org code fails over the appstream id no longer being a 1:1 map of the desktop file name, due to the - in the id now being a _. Filed https://invent.kde.org/websites/apps-kde-org/-/issues/35 to have this fixed in the web site generation hopefully by some good person with knowledge, as appstream docs do not require any relationship here, rather document that the desktop file name is taken from the launchable tag ideally. So the apps.kde.org might try to follow that also? Cheers Friedrich
Re: KDE Gear projects with failing CI (master) (21 May 2024)
On Wed, May 22, 2024 at 9:24 AM Albert Astals Cid 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. > > > massif-visualizer - NEW > * https://invent.kde.org/sdk/massif-visualizer/-/pipelines/693832 > * appstreamtest fails because https://apps.kde.org/massif-visualizer > doesn't > exist > > > baloo-widgets - NEW > * https://invent.kde.org/libraries/baloo-widgets/-/pipelines/693837 > * filemetadataitemcounttest failed in Linux Qt 6.7 > > > tokodon - NEW > * https://invent.kde.org/network/tokodon/-/pipelines/693844 > * TimelineTest failed in Linux Qt 6.7 > > > okular - NEW > * https://invent.kde.org/graphics/okular/-/pipelines/693821 > * craft mac and windows failed, possibly in codesign? > > > kdenlive - NEW > * https://invent.kde.org/multimedia/kdenlive/-/pipelines/693822 > * craft windows failed, possibly in codesign? > * craft mac has been stuck for hours, builder down? > > > > Cheers, > Albert > Cheers, Ben
Re: KDE Gear projects with failing CI (master) (21 May 2024)
On Mittwoch, 22. Mai 2024 10:27:07 CEST Ben Cooksley wrote: > On Wed, May 22, 2024 at 9:24 AM Albert Astals Cid 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)? Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (master) (21 May 2024)
On Fri, May 24, 2024 at 4:13 AM Volker Krause 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 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. The dependency chain is also @same as both are part of KDE Gear so from a technical perspective that doesn't work either. >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... The only fix is to either drop Qt 5 support from kio-gdrive, or to restore Qt 5 support to libkgapi. > > > Regards, > Volker > Cheers, Ben
Re: KDE Gear projects with failing CI (master) (21 May 2024)
On Freitag, 24. Mai 2024 12:24:16 CEST Ben Cooksley wrote: > On Fri, May 24, 2024 at 4:13 AM Volker Krause 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 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. > 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? > 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. > 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. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (master) (21 May 2024)
On Sat, May 25, 2024 at 3:09 AM Volker Krause wrote: > On Freitag, 24. Mai 2024 12:24:16 CEST Ben Cooksley wrote: > > On Fri, May 24, 2024 at 4:13 AM Volker Krause 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 > 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. > > > 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? > > > 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) 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 > > Regards, > Volker Cheers, Ben
Re: KDE Gear projects with failing CI (master) (21 May 2024)
On Samstag, 25. Mai 2024 13:34:53 CEST Ben Cooksley wrote: > On Sat, May 25, 2024 at 3:09 AM Volker Krause wrote: > > On Freitag, 24. Mai 2024 12:24:16 CEST Ben Cooksley wrote: > > > On Fri, May 24, 2024 at 4:13 AM Volker Krause 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 > > > > 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? 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). > > > 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 :) > 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
Re: KDE Gear projects with failing CI (master) (21 May 2024)
On Sun, May 26, 2024 at 6:59 PM Volker Krause wrote: > On Samstag, 25. Mai 2024 13:34:53 CEST Ben Cooksley wrote: > > On Sat, May 25, 2024 at 3:09 AM Volker Krause wrote: > > > On Freitag, 24. Mai 2024 12:24:16 CEST Ben Cooksley wrote: > > > > On Fri, May 24, 2024 at 4:13 AM Volker Krause > 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 > > > > > > > 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 prob
