Re: KDE Gear projects with failing CI (release/24.02) (6 February 2024)
On Tuesday, 6 February 2024 22:24:22 CET, Albert Astals Cid wrote: Bad news: 3 repositories are still failing and 11 new repositories started failing kdialog - NEW * https://invent.kde.org/utilities/kdialog/-/pipelines/601189 * flatpak fails in icon-not-found kmag - NEW * https://invent.kde.org/accessibility/kmag/-/pipelines/601207 * flatpak fails in icon-not-found kbackup - NEW * https://invent.kde.org/utilities/kbackup/-/pipelines/601223 * flatpak fails in icon-not-found kirigami-gallery - NEW * https://invent.kde.org/sdk/kirigami-gallery/-/pipelines/601366 * flatpak fails in icon-not-found All of the above are fixed now.
Re: KDE Gear projects with failing CI (release/24.02) (6 February 2024)
On Thu, Feb 8, 2024 at 7:17 AM Friedrich W. H. Kossebau wrote: > Am Mittwoch, 7. Februar 2024, 11:48:57 CET schrieb Ben Cooksley: > > All of the Games Flatpak failures are caused by > > > https://invent.kde.org/games/libkdegames/-/commit/023d1a7b173f9d28453a0268e9 > > 1ad1ccb47054b9 I intend to revert that commit in 24 hours unless a > suitable > > explaination can be provided as to why 6.0.0 is actually required. > > > > All that commit has done is cause unnecessary breakage as I can't see > > commits before or after it that justify that bump. > > The purpose of the commits (to libkdegames & libkmahjongg, actually > planned to > do for all of kdegames repos for consistency) has been to test that things > still build everywhere when the major version in the min required KF > version > is changed (5.x to 6.x). > As such major version number change has been the cause for issues in the > past, > as some logic relies on that number sometimes. > So it felt better also tested with KF6 now before the 6.0.0 release > (compare > e.g. the struggles Plasma has had with its major version number-based > logic > recently). > > And while those commits are the trigger, the cause is the design flaw of > the > flatpak jobs on "CI", which now exclude KF from CI & CD on the development > branches, restrict the use of KF API to released versions. > > To get things rolling again for now, I have reverted the two commits now, > removing the trigger again. > > I hope people find a solution to that challenge > they created here though, because this seems a bit the tail (packaging/ > delivery) wagging with the body (development). > > If things break somewhere over the major version number in the dep > version, I > can say I tried ;) > It's more a reflection of how Flatpak works where applications are built on top of a runtime. In our case, to avoid every single application needing to build every single Framework (and wasting copious amounts of disk space not to mention build CPU time in the process) we place Qt and KDE Frameworks in a runtime so they can be shared. For those curious as to how long it takes to build this runtime (excluding QtWebEngine) see https://invent.kde.org/packaging/flatpak-kde-runtime/-/jobs/1561108 - yes, it takes 2 hours on one of our CI nodes to build. Not something that is practical to build every time you build an application. Craft also has a similar issue as by default it provides the latest released version of dependencies unless that is otherwise explicitly overridden. Using that override though that means it has to build the dependencies you've overridden every single time it performs a build - which is not an efficient use of resources. As such it should be used sparingly, if at all, and only if absolutely needed. In general the expectation is that KDE applications (which is what all these continuous delivery pipelines are aimed at) aim to build as a minimum requirement against the latest released versions of things not in their release unit (such as Frameworks). This also makes it easier for new contributors to "jump in" as they can use the development packages shipped by their distribution rather than needing to build the world first (which is going to put a new contributor off). This is in line with the precedent set over the entire lifetime of our Qt 5 based releases, where Frameworks, Release Service and independently released applications all had independent release schedules and version schemes. I appreciate that major version bumps can cause all sorts of breakage though, i'm expecting some degree of breakage no matter how much we pre-test. > > Cheers > Friedrich > > Cheers, Ben
Re: KDE Gear projects with failing CI (release/24.02) (6 February 2024)
Am Mittwoch, 7. Februar 2024, 11:48:57 CET schrieb Ben Cooksley: > All of the Games Flatpak failures are caused by > https://invent.kde.org/games/libkdegames/-/commit/023d1a7b173f9d28453a0268e9 > 1ad1ccb47054b9 I intend to revert that commit in 24 hours unless a suitable > explaination can be provided as to why 6.0.0 is actually required. > > All that commit has done is cause unnecessary breakage as I can't see > commits before or after it that justify that bump. The purpose of the commits (to libkdegames & libkmahjongg, actually planned to do for all of kdegames repos for consistency) has been to test that things still build everywhere when the major version in the min required KF version is changed (5.x to 6.x). As such major version number change has been the cause for issues in the past, as some logic relies on that number sometimes. So it felt better also tested with KF6 now before the 6.0.0 release (compare e.g. the struggles Plasma has had with its major version number-based logic recently). And while those commits are the trigger, the cause is the design flaw of the flatpak jobs on "CI", which now exclude KF from CI & CD on the development branches, restrict the use of KF API to released versions. To get things rolling again for now, I have reverted the two commits now, removing the trigger again. I hope people find a solution to that challenge they created here though, because this seems a bit the tail (packaging/ delivery) wagging with the body (development). If things break somewhere over the major version number in the dep version, I can say I tried ;) Cheers Friedrich
Re: KDE Gear projects with failing CI (release/24.02) (6 February 2024)
On Dienstag, 6. Februar 2024 22:24:22 CET 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: 7 failing repositories from previous report got fixed > > Bad news: 3 repositories are still failing and 11 new repositories started > failing > > > gwenview - 3rd week > * https://invent.kde.org/graphics/gwenview/-/pipelines/601196 > * cfitsio SHA doesn't match on flatpak build That has been fixed by backporting the corresponding fix from master. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (release/24.02) (6 February 2024)
On Wed, Feb 7, 2024 at 10: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: 7 failing repositories from previous report got fixed > > Bad news: 3 repositories are still failing and 11 new repositories started > failing > > > gwenview - 3rd week > * https://invent.kde.org/graphics/gwenview/-/pipelines/601196 > * cfitsio SHA doesn't match on flatpak build > > > dolphin - 2nd week > * https://invent.kde.org/system/dolphin/-/pipelines/601190 > * flatpak fails in icon-not-found > > > ark - 2nd week > * https://invent.kde.org/utilities/ark/-/pipelines/601200 > * FreeBSD tests failed > > > kdialog - NEW > * https://invent.kde.org/utilities/kdialog/-/pipelines/601189 > * flatpak fails in icon-not-found > > > kmag - NEW > * https://invent.kde.org/accessibility/kmag/-/pipelines/601207 > * flatpak fails in icon-not-found > > > kbackup - NEW > * https://invent.kde.org/utilities/kbackup/-/pipelines/601223 > * flatpak fails in icon-not-found > > > kirigami-gallery - NEW > * https://invent.kde.org/sdk/kirigami-gallery/-/pipelines/601366 > * flatpak fails in icon-not-found > > > kbounce - NEW > * https://invent.kde.org/games/kbounce/-/pipelines/601210 > * flatpak fails because code requires an unreleased ECM > > > kdiamond - NEW > * https://invent.kde.org/games/kdiamond/-/pipelines/601211 > * flatpak fails because code requires an unreleased ECM > > > kmahjongg - NEW > * https://invent.kde.org/games/kmahjongg/-/pipelines/601212 > * flatpak fails because code requires an unreleased ECM > > > kpat - NEW > * https://invent.kde.org/games/kpat/-/pipelines/601213 > * flatpak fails because code requires an unreleased ECM > > > ksudoku - NEW > * https://invent.kde.org/games/ksudoku/-/pipelines/601215 > * flatpak fails because code requires an unreleased ECM > > > kubrick - NEW > * https://invent.kde.org/games/kubrick/-/pipelines/601216 > * flatpak fails because code requires an unreleased ECM > > > palapeli - NEW > * https://invent.kde.org/games/palapeli/-/pipelines/601217 > * flatpak fails because code requires an unreleased ECM > All of the Games Flatpak failures are caused by https://invent.kde.org/games/libkdegames/-/commit/023d1a7b173f9d28453a0268e91ad1ccb47054b9 I intend to revert that commit in 24 hours unless a suitable explaination can be provided as to why 6.0.0 is actually required. All that commit has done is cause unnecessary breakage as I can't see commits before or after it that justify that bump. The icon-not-found failures all appear to be due to something in Flatpak or Appstream, so one of the developers from those respective software stacks needs to take a look given nothing on our side changed. The price of using Fedora (who upgrades things in stable distros far too aggressively) for the flatpak-builder image on our CI system (I should probably swap it out for a more stable / normal distribution...) > > > Cheers, > Albert > Cheers, Ben
