Re: KDE Frameworks with failing CI (master) (4 February 2024)
On 2024-02-04 19:05, Ben Cooksley wrote: On Mon, Feb 5, 2024 at 1:26 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: 3 repository has been fixed Bad news: 2 repositories are still failing, 3 new ones have started failing baloo - 2nd week * https://invent.kde.org/frameworks/baloo/-/pipelines/598254 * FreeBSD tests are failing baloo is fixed with https://invent.kde.org/frameworks/kfilemetadata/-/merge_requests/126 too. kfilemetadata - 2nd week * https://invent.kde.org/frameworks/kfilemetadata/-/pipelines/598257 * FreeBSD tests are failing This one has been debugged by Christoph and there is a pending MR to fix this. See https://invent.kde.org/frameworks/kfilemetadata/-/merge_requests/126 Caused by differences in the FreeBSD / Linux APIs and the newer versions of FreeBSD / ZFS being more strict on the input they're given for attribute names. (so yes, there was an actual bug here) kdav - NEW * https://invent.kde.org/frameworks/kdav/-/pipelines/598256 * davcollectionsmultifetchjobtest fails both in Linux and FreeBSD ki18n - NEW * https://invent.kde.org/frameworks/ki18n/-/pipelines/598258 * Linux tests are failing The Linux image was recently rebuilt, possibly caused by newer dependencies coming through. kuserfeedback - NEW * https://invent.kde.org/frameworks/kuserfeedback/-/pipelines/598260 * flatpak is failing (the SDK needs updating?) https://invent.kde.org/packaging/flatpak-kde-runtime/-/commit/ddfdb201e65cfebdd33323a6752ff5e5fc475001 https://invent.kde.org/packaging/flatpak-kde-runtime/-/jobs/1560506 Once that has passed, a rebuild of the flatpak-builder CI image will be needed, then that will be fixed. Cheers, Albert Cheers, Ben
Reminder: KF6 Meeting
Hello everyone, please remember the KF6 meeting tomorrow, Tuesday 17:00 CET: https://meet.kde.org/b/ada-mi8-aem Topics and notes are collected here: https://invent.kde.org/teams/frameworks-devs/kf6-workboard/-/issues/75 Thank you, Volker signature.asc Description: This is a digitally signed message part.
Re: KDE Frameworks with failing CI (master) (4 February 2024)
On Sonntag, 4. Februar 2024 13:26:54 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: 3 repository has been fixed > > Bad news: 2 repositories are still failing, 3 new ones have started failing > > > kdav - NEW > * https://invent.kde.org/frameworks/kdav/-/pipelines/598256 > * davcollectionsmultifetchjobtest fails both in Linux and FreeBSD Bisecting points to the following KIO MR as the cause: https://invent.kde.org/frameworks/kio/-/merge_requests/1543 Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: Flatpak jobs on KDE CI vs. continuous integration on main/master/devel branches
On Mon, Feb 5, 2024 at 4:28 AM Friedrich W. H. Kossebau wrote: > Hi, > > ((cc:kde-frameworks-devel for heads-up, replies please only to > kde-core-deve)) > > I hit the problem that when working on a repo which would like to use > latest > KF development state to integrate some new KF API just added in > cooperation > with that very repo wanting to use it, I cannot do so when someone had > added a > flatpak job on CI to that repo. > > Because with such flatpak jobs it seems they are limiting the available KF > version not to the current latest one, as expected for continuous > integration, > but some older (anywhere documented?) snapshot: > > "runtime-version": "6.6-kf6preview", > > What can be done here to reestablish the old immediate continuous > integration > workflow? Where new APIs (also from KF) are instantly available? > > Right now this is a new extra burden which makes working on new features > with > KF and apps more complicated. Thus less interesting, and one/I would > rather > duplicate code in apps to get things done. > > Blocking latest KF API from usage also means less testing of that before > the > initial release. > > Besides all the resource costs to create flatpaks on master builds by > default > every time, when those are usually not used by anyone anyway. > > So, how to solve those problems? Did I miss something? > Could flatpak builds on master branches be made on-demand rather? > For the record, my rebuild of the 6.6-kf6preview Flatpak Runtime/SDK was successful, and the failure that kicked this off in KUserFeedback has now been fixed. https://invent.kde.org/frameworks/kuserfeedback/-/jobs/1561435 > Cheers > Friedrich > > > Cheers, Ben
