Re: KDE Gear projects with failing CI (release/24.02) (2 April 2024)

[Ben Cooksley]

On Thu, Apr 11, 2024 at 1:15 AM Ralf Habacker 
wrote:

> Am 10.04.24 um 10:51 schrieb Ben Cooksley:
> > umbrello - 3rd week
> >   * https://invent.kde.org/sdk/umbrello/-/pipelines/657665
> > 
> >* craft_windows_qt515_x86_64 fails
> >
>
> This issue depends on a special dependency requirement in a third party
> package, see
>
> https://invent.kde.org/packaging/craft-blueprints-kde/-/blob/master/extragear/kdevelop/kdevelop/kdevelop.py?ref_type=heads#L30
>
> Currently I have no idea how to fix this - Any hint welcome.
>

This was discussed in #kde-craft a week or so ago.
Hopefully
https://invent.kde.org/packaging/craft-blueprints-kde/-/merge_requests/827
will resolve this.


>
> Regards
> Ralf
>
>
Cheers,
Ben

Re: KDE Gear projects with failing CI (master) (9 April 2024)

[Ingo Klöcker]

On Mittwoch, 10. April 2024 14:54:26 CEST Friedrich W. H. Kossebau wrote:
> Am Mittwoch, 10. April 2024, 14:29:37 CEST schrieb Ingo Klöcker:
> > On Mittwoch, 10. April 2024 13:33:46 CEST Friedrich W. H. Kossebau wrote:
> > > Am Mittwoch, 10. April 2024, 13:04:47 CEST schrieb Ingo Klöcker:
> > > > On Mittwoch, 10. April 2024 09:21:34 CEST Ben Cooksley wrote:
> > > > > On Wed, Apr 10, 2024 at 9:51 AM Ingo Klöcker  
wrote:
> > > > > > On Dienstag, 9. April 2024 23:26:32 CEST Albert Astals Cid wrote:
> > > > > > > ktrip - NEW
> > > > > > > 
> > > > > > >  * https://invent.kde.org/utilities/ktrip/-/pipelines/657661
> > > > > > >  
> > > > > > >   * craft_android builds fail
> > > > > > 
> > > > > > *sigh* Why does kirigami master depend on the not yet released ECM
> > > > > > 6.1.0?
> > > > > 
> > > > > Likely as Kirigami itself is a Framework - that being said, it seems
> > > > > a
> > > > > bit
> > > > > weird for the version bumps to be pushed to Frameworks before the
> > > > > release
> > > > > has been made public (because Craft cannot use them until they're
> > > > > public...)
> > > > 
> > > > I learned that this is the usual procedure for Frameworks. But it
> > > > highlights why it's a bad idea for applications to depend on the
> > > > master
> > > > versions of Frameworks.
> > > 
> > > In (software) development it seems usually fine to have development
> > > branches of separate components depend on each other's latest state.
> > > They
> > > call it Continuous Integration. One of the purposes is to get
> > > early-as-possible feedback, not only post-release when certain things
> > > can
> > > no longer be changed. In the case of KF libraries that would be e.g.
> > > feasibility of new API as well as the state of the implementation. Which
> > > is usually considered a good idea, both for the libraries as well as the
> > > applications as the consumers of the libraries.
> > > 
> > > It is a bad idea only from the POV of Craft users, as the tool seems not
> > > yet capable to deal with development branches of all dependencies?
> > 
> > It does support this but it will kill our CI/CD system if every Craft CD
> > job builds all Frameworks from scratch. In any case, what you talk about
> > is covered by the CI (Continuous Integration!) jobs.
> > 
> > The Craft CD (Continuous Delivery/Deployment) jobs are meant to be used
> > for
> > building releases. When we stop doing fixed point releases and start doing
> > continuous releases of Frameworks then we can talk about doing CD from
> > master.
> 
> Hm, not sure if we talk along the same lines. Let's summarize what I saw
> here:
> 
> 1. craft-tool based job on master branch of app fails
> 2. reason: master branch of app expects master branch of library, job though
> only supplies released version of that library

I'd say this statement is wrong, but that depends on what you mean by 
"expects". The master branch of KTrip doesn't require (as in CMake's 
find_package()) the master branch of Kirigami. And the job did actually (try 
to) supply the master branch of Kirigami. But that failed because the master 
branch of Kirigami requires ECM 6.1 which the job didn't supply.

> 3. claim: "highlights why it's a bad idea for applications to depend on the
> master versions of Frameworks"

Because one cannot use the master versions of a few selected Frameworks for a 
build. One needs to use the master versions of all of Frameworks. And that's 
expensive.

> 4. "Craft CD jobs are meant to be used for building releases"
> 
> So why are there Craft CD jobs on master branches of apps?

Some apps do actually do Continuous Delivery, e.g. Itinerary. But that's only 
possible because Itinerary doesn't depend on unreleased Frameworks. (Well, it 
would be possible otherwise but it would cost/waste much more CI/CD 
resources.)

Some projects want users to be able to check out the bleeding edge AppImage or 
Flatpak of their app. Same for Windows builds. This is certainly useful for 
example to check if bugs in some release still occur in the development 
version.

The problem isn't "Craft CD jobs on master branches of apps". The problem is 
"Craft CD jobs on master branches of apps" which require unreleased 
Frameworks.

> Or what kind of Craft jobs are those?

All of them.

> My point is: it is not a bad idea for applications to depend on master
> versions of Frameworks, for the reasons given in my response.

I agree that it's not a bad idea in general if the devs of the app have good 
reasons to do so. They have to take into account that long running CD jobs 
waste energy and the time of people waiting for the jobs to finish. In general, 
it's better to avoid depending on unreleased Frameworks.

I would likely not contribute to a project which forces me to build Frameworks 
myself. I'm a happy user of the KF development packages provided by 
Tumbleweed.

Regards,
Ingo

signature.asc
Description: This is a digitally signed message part.

Re: KDE Gear projects with failing CI (release/24.02) (2 April 2024)

[Ralf Habacker]

Am 10.04.24 um 10:51 schrieb Ben Cooksley:

umbrello - 3rd week
  * https://invent.kde.org/sdk/umbrello/-/pipelines/657665 


   * craft_windows_qt515_x86_64 fails



This issue depends on a special dependency requirement in a third party 
package, see 
https://invent.kde.org/packaging/craft-blueprints-kde/-/blob/master/extragear/kdevelop/kdevelop/kdevelop.py?ref_type=heads#L30


Currently I have no idea how to fix this - Any hint welcome.

Regards
Ralf

Re: KDE Gear projects with failing CI (master) (9 April 2024)

[Friedrich W. H. Kossebau]

Am Mittwoch, 10. April 2024, 14:29:37 CEST schrieb Ingo Klöcker:
> On Mittwoch, 10. April 2024 13:33:46 CEST Friedrich W. H. Kossebau wrote:
> > Am Mittwoch, 10. April 2024, 13:04:47 CEST schrieb Ingo Klöcker:
> > > On Mittwoch, 10. April 2024 09:21:34 CEST Ben Cooksley wrote:
> > > > On Wed, Apr 10, 2024 at 9:51 AM Ingo Klöcker  wrote:
> > > > > On Dienstag, 9. April 2024 23:26:32 CEST Albert Astals Cid wrote:
> > > > > > ktrip - NEW
> > > > > > 
> > > > > >  * https://invent.kde.org/utilities/ktrip/-/pipelines/657661
> > > > > >  
> > > > > >   * craft_android builds fail
> > > > > 
> > > > > *sigh* Why does kirigami master depend on the not yet released ECM
> > > > > 6.1.0?
> > > > 
> > > > Likely as Kirigami itself is a Framework - that being said, it seems a
> > > > bit
> > > > weird for the version bumps to be pushed to Frameworks before the
> > > > release
> > > > has been made public (because Craft cannot use them until they're
> > > > public...)
> > > 
> > > I learned that this is the usual procedure for Frameworks. But it
> > > highlights why it's a bad idea for applications to depend on the master
> > > versions of Frameworks.
> > 
> > In (software) development it seems usually fine to have development
> > branches of separate components depend on each other's latest state. They
> > call it Continuous Integration. One of the purposes is to get
> > early-as-possible feedback, not only post-release when certain things can
> > no longer be changed. In the case of KF libraries that would be e.g.
> > feasibility of new API as well as the state of the implementation. Which
> > is usually considered a good idea, both for the libraries as well as the
> > applications as the consumers of the libraries.
> > 
> > It is a bad idea only from the POV of Craft users, as the tool seems not
> > yet capable to deal with development branches of all dependencies?
> 
> It does support this but it will kill our CI/CD system if every Craft CD job
> builds all Frameworks from scratch. In any case, what you talk about is
> covered by the CI (Continuous Integration!) jobs.
> 
> The Craft CD (Continuous Delivery/Deployment) jobs are meant to be used for
> building releases. When we stop doing fixed point releases and start doing
> continuous releases of Frameworks then we can talk about doing CD from
> master.

Hm, not sure if we talk along the same lines. Let's summarize what I saw here:

1. craft-tool based job on master branch of app fails
2. reason: master branch of app expects master branch of library, job though 
only supplies released version of that library
3. claim: "highlights why it's a bad idea for applications to depend on the 
master versions of Frameworks"
4. "Craft CD jobs are meant to be used for building releases"

So why are there Craft CD jobs on master branches of apps? Or what kind of 
Craft jobs are those? 

My point is: it is not a bad idea for applications to depend on master 
versions of Frameworks, for the reasons given in my response.

So what is the context of that claim stating the opposite?

Cheers
Friedrich

Re: KDE Gear projects with failing CI (master) (9 April 2024)

[Ingo Klöcker]

On Mittwoch, 10. April 2024 13:33:46 CEST Friedrich W. H. Kossebau wrote:
> Am Mittwoch, 10. April 2024, 13:04:47 CEST schrieb Ingo Klöcker:
> > On Mittwoch, 10. April 2024 09:21:34 CEST Ben Cooksley wrote:
> > > On Wed, Apr 10, 2024 at 9:51 AM Ingo Klöcker  wrote:
> > > > On Dienstag, 9. April 2024 23:26:32 CEST Albert Astals Cid wrote:
> > > > > ktrip - NEW
> > > > > 
> > > > >  * https://invent.kde.org/utilities/ktrip/-/pipelines/657661
> > > > >  
> > > > >   * craft_android builds fail
> > > > 
> > > > *sigh* Why does kirigami master depend on the not yet released ECM
> > > > 6.1.0?
> > > 
> > > Likely as Kirigami itself is a Framework - that being said, it seems a
> > > bit
> > > weird for the version bumps to be pushed to Frameworks before the
> > > release
> > > has been made public (because Craft cannot use them until they're
> > > public...)
> > 
> > I learned that this is the usual procedure for Frameworks. But it
> > highlights why it's a bad idea for applications to depend on the master
> > versions of Frameworks.
> 
> In (software) development it seems usually fine to have development branches
> of separate components depend on each other's latest state. They call it
> Continuous Integration. One of the purposes is to get early-as-possible
> feedback, not only post-release when certain things can no longer be
> changed. In the case of KF libraries that would be e.g. feasibility of new
> API as well as the state of the implementation. Which is usually considered
> a good idea, both for the libraries as well as the applications as the
> consumers of the libraries.
> 
> It is a bad idea only from the POV of Craft users, as the tool seems not yet
> capable to deal with development branches of all dependencies?

It does support this but it will kill our CI/CD system if every Craft CD job 
builds all Frameworks from scratch. In any case, what you talk about is 
covered by the CI (Continuous Integration!) jobs.

The Craft CD (Continuous Delivery/Deployment) jobs are meant to be used for 
building releases. When we stop doing fixed point releases and start doing 
continuous releases of Frameworks then we can talk about doing CD from master.

Regards,
Ingo

signature.asc
Description: This is a digitally signed message part.

Re: KDE Gear projects with failing CI (master) (9 April 2024)

[Friedrich W. H. Kossebau]

Am Mittwoch, 10. April 2024, 13:04:47 CEST schrieb Ingo Klöcker:
> On Mittwoch, 10. April 2024 09:21:34 CEST Ben Cooksley wrote:
> > On Wed, Apr 10, 2024 at 9:51 AM Ingo Klöcker  wrote:
> > > On Dienstag, 9. April 2024 23:26:32 CEST Albert Astals Cid wrote:
> > > > ktrip - NEW
> > > > 
> > > >  * https://invent.kde.org/utilities/ktrip/-/pipelines/657661
> > > >  
> > > >   * craft_android builds fail
> > > 
> > > *sigh* Why does kirigami master depend on the not yet released ECM
> > > 6.1.0?
> > 
> > Likely as Kirigami itself is a Framework - that being said, it seems a bit
> > weird for the version bumps to be pushed to Frameworks before the release
> > has been made public (because Craft cannot use them until they're
> > public...)
> I learned that this is the usual procedure for Frameworks. But it highlights
> why it's a bad idea for applications to depend on the master versions of
> Frameworks.

In (software) development it seems usually fine to have development branches 
of separate components depend on each other's latest state. They call it 
Continuous Integration. One of the purposes is to get early-as-possible 
feedback, not only post-release when certain things can no longer be changed.
In the case of KF libraries that would be e.g. feasibility of new API as well 
as the state of the implementation. Which is usually considered a good idea, 
both for the libraries as well as the applications as the consumers of the 
libraries.

It is a bad idea only from the POV of Craft users, as the tool seems not yet 
capable to deal with development branches of all dependencies?
E.g. kdesrc-build/kde-build though e.g. are capable, so let's hope some Craft 
developers/users are inspired to have their tool catch up.

Even more when Craft is thought to also support early testing by users of new 
features/implementation (that is why you do packages for app development 
states here, right?), where development branches of the respective libraries 
adding to that also want/need to be covered.

Cheers
Friedrich

Re: KDE Gear projects with failing CI (master) (9 April 2024)

[Ingo Klöcker]

On Mittwoch, 10. April 2024 09:21:34 CEST Ben Cooksley wrote:
> On Wed, Apr 10, 2024 at 9:51 AM Ingo Klöcker  wrote:
> > On Dienstag, 9. April 2024 23:26:32 CEST Albert Astals Cid wrote:
> > > ktrip - NEW
> > > 
> > >  * https://invent.kde.org/utilities/ktrip/-/pipelines/657661
> > >  
> > >   * craft_android builds fail
> > 
> > *sigh* Why does kirigami master depend on the not yet released ECM 6.1.0?
> 
> Likely as Kirigami itself is a Framework - that being said, it seems a bit
> weird for the version bumps to be pushed to Frameworks before the release
> has been made public (because Craft cannot use them until they're public...)

I learned that this is the usual procedure for Frameworks. But it highlights 
why it's a bad idea for applications to depend on the master versions of 
Frameworks.

> The real question I have though is why does KTrip depend on Frameworks
> master instead of released Frameworks?
> Depending on Frameworks master is something applications should avoid
> unless it is absolutely necessary.

Exactly. ktrip needs a fix that's not in KF 6.0. Instead of adding a patch to 
Craft I told Craft to use Kirigami master. I shouldn't have done this. Lesson 
learned.

Regards,
Ingo


signature.asc
Description: This is a digitally signed message part.

Re: KDE Frameworks with failing CI (master) (7 April 2024)

[Ben Cooksley]

On Wed, Apr 10, 2024 at 4:33 AM Volker Krause  wrote:

> On Sonntag, 7. April 2024 23:02:06 CEST 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.
> >
> > Bad news: 3 repositories have started failing
> >
> > kconfigwidgets - NEW
> >  * https://invent.kde.org/frameworks/kconfigwidgets/-/pipelines/655246
> >   * klanguagenametest fails in Linux
> >*
> https://invent.kde.org/frameworks/kconfigwidgets/-/merge_requests/234
> >
> >
> > kcontacts - NEW
> >  * https://invent.kde.org/frameworks/kcontacts/-/pipelines/655247
> >   * AddressTest::formatTest fails in FreeBSD
>
> That's the same issue that also hit kitinerary. As I haven't gotten any
> answers for my questions about what changed on the CI there I've now
> disabled
> this test for FreeBSD for kitinerary, I can do the same for KContacts I
> guess.
>

To give a public answer about this - there was a general image rebuild to
take into account a number of updates to various libraries.
It seems something in the FreeBSD stack has gotten loose as part of this so
we'll need to do some more investigation.


>
> > kuserfeedback - NEW
> >  * https://invent.kde.org/frameworks/kuserfeedback/-/pipelines/655248
> >   * The code requires unreleased versions so flatpak fails
>
> Hm, that's a systematic problem: We cannot do Flatpak builds in a KF
> master
> branch on top of an existing runtime.
>
> Doing Flatpak builds only in the stable branch wont work here given there
> is
> no such branch. So the options I can think of are either building all KF
> dependencies explicitly here rather than using those from the runtime, or
> splitting the management/analytics tools (which is what the Flatpak is
> actually for) from the library.
>

I'd probably suggest splitting them at this stage given the issues we keep
hitting here...


>
> Regards,
> Volker


Cheers,
Ben

Re: KDE Gear projects with failing CI (release/24.02) (2 April 2024)

[Ben Cooksley]

On Wed, Apr 10, 2024 at 9:33 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: 1 repository was fixed
>
> Bad news: 2 repositories are still failing and 6 repositories has started
> failing
>
> kirigami-gallery - 3rd week
>  * https://invent.kde.org/sdk/kirigami-gallery/-/pipelines/657676
>   * Android build fails
>
>
> umbrello - 3rd week
>  * https://invent.kde.org/sdk/umbrello/-/pipelines/657665
>   * craft_windows_qt515_x86_64 fails
>
>
> krdc - NEW
>  * https://invent.kde.org/network/krdc/-/pipelines/657666
>   * Linux builds fail because of missing dependencies
>

Christophe sent some merge requests earlier for Qt 6 which resolved that
side of our CI images, however Qt 5.15 was missed.
I've aligned that this evening and rebuilt the SUSE CI images.


>
>
> ktrip - NEW
>  * https://invent.kde.org/utilities/ktrip/-/pipelines/657677
>   * craft builds fail
>
> tokodon - NEW
>  * https://invent.kde.org/network/tokodon/-/pipelines/657678
>   * tokodon-searchtest fails in Linux and FreeBSD
>
>
> dolphin - NEW
>  * https://invent.kde.org/system/dolphin/-/pipelines/657664
>   * flatpak fails because it is building baloo from master instead of
> stable
>
>
> arianna - NEW
>  * https://invent.kde.org/graphics/arianna/-/pipelines/657679
>   * flatpak fails because it is building baloo from master instead of
> stable
>
>
> pim-sieve-editor - NEW
>  * https://invent.kde.org/pim/pim-sieve-editor/-/pipelines/657670
>   * flatpak fails because it is building ktexttemplate from master instead
> of
> stable
>
>
> Cheers,
>   Albert
>

Cheers,
Ben

Re: KDE Gear projects with failing CI (master) (9 April 2024)

[Ben Cooksley]

On Wed, Apr 10, 2024 at 9: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 repositories got fixed
>
> Bad news: 2 repositories still failing and new 5 repositories failing this
> week
>
>
> umbrello - 3rd week
>  * https://invent.kde.org/sdk/umbrello/-/pipelines/657654
>   * craft_windows_qt515_x86_64 fails
>
>
> kirigami-gallery - 3rd week
>  * https://invent.kde.org/sdk/kirigami-gallery/-/pipelines/657659
>   * Android build fails


Waiting on Craft to be ready to bump to Qt 6.7 which will be soon.


>
>
>
> kdenlive - NEW
>  * https://invent.kde.org/multimedia/kdenlive/-/pipelines/657653
>   * flatpak fails, shasum changed?
>
>
> kldap - NEW
>  * https://invent.kde.org/pim/kldap/-/pipelines/657656
>   * Windows build fails because it can't find Qt6Keychain
>
>
> kmailtransport - NEW
>  * https://invent.kde.org/pim/kmailtransport/-/pipelines/657657
>   * Windows build fails because it can't find Qt6Keychain
>
>
> pim-sieve-editpr - NEW
>  * https://invent.kde.org/pim/pim-sieve-editor/-/pipelines/657658
>   * Windows build fails because it can't find Qt6Keychain
>

Carl has temporarily patched these to keep the lower version in place for
Windows.
PIM developers are reminded to not just arbitrarily bump dependencies but
to use merge requests and ask/file tickets before bumping dependencies.

Craft will soon update here as part of the Qt 6.7 bump.


>
>
> ktrip - NEW
>  * https://invent.kde.org/utilities/ktrip/-/pipelines/657661
>   * craft_android builds fail
>

Probably worth waiting for the Craft Qt 6.7 bump to see how this works out.


>
> Cheers,
>   Albert
>
>
>
Cheers,
Ben

[sysadmin/ci-images] /: Ensure we include QtKeychain in our Windows images for Qt 5.15 and Qt 6.6.

[Ben Cooksley]

Git commit 9b33873bf75e362f24d6b03a2c7873fb5fa16668 by Ben Cooksley.
Committed on 10/04/2024 at 08:42.
Pushed by bcooksley into branch 'master'.

Ensure we include QtKeychain in our Windows images for Qt 5.15 and Qt 6.6.

This dependency on QtKeychain was added by PIM developers to KLDAP, 
KMailTransport and PIM Sieve Editor without any form of advance notice to 
Sysadmin.
PIM Developers: You are reminded yet again, please give advance notice of 
changes to external dependencies.

CCMAIL: kde-devel@kde.org
CCMAIL: kde-...@kde.org

M  +3-0windows-msvc2019-qt515/CI-Craft-Packages.list
M  +3-0windows-msvc2022-qt66/CI-Craft-Packages.shelf

https://invent.kde.org/sysadmin/ci-images/-/commit/9b33873bf75e362f24d6b03a2c7873fb5fa16668

diff --git a/windows-msvc2019-qt515/CI-Craft-Packages.list 
b/windows-msvc2019-qt515/CI-Craft-Packages.list
index 10f19da..23541c3 100644
--- a/windows-msvc2019-qt515/CI-Craft-Packages.list
+++ b/windows-msvc2019-qt515/CI-Craft-Packages.list
@@ -88,6 +88,9 @@ libs/fluidsynth
 # KCalCore
 libs/libical
 
+# KMailTransport, KLDAP and PIM Sieve Editor
+qt-libs/qtkeychain
+
 # Analitza
 libs/glew
 
diff --git a/windows-msvc2022-qt66/CI-Craft-Packages.shelf 
b/windows-msvc2022-qt66/CI-Craft-Packages.shelf
index 852233c..845b029 100644
--- a/windows-msvc2022-qt66/CI-Craft-Packages.shelf
+++ b/windows-msvc2022-qt66/CI-Craft-Packages.shelf
@@ -101,6 +101,9 @@ blueprintrepositories = 
https://invent.kde.org/packaging/craft-blueprints-kde.gi
 ## KCalCore
 [libs/libical]
 
+## KMailTransport, KLDAP and PIM Sieve Editor
+[qt-libs/qtkeychain]
+
 ## Analitza
 [libs/glew]
 

Re: KDE Gear projects with failing CI (master) (9 April 2024)

[Ben Cooksley]

On Wed, Apr 10, 2024 at 9:51 AM Ingo Klöcker  wrote:

> On Dienstag, 9. April 2024 23:26:32 CEST Albert Astals Cid wrote:
> > ktrip - NEW
> >  * https://invent.kde.org/utilities/ktrip/-/pipelines/657661
> >   * craft_android builds fail
>
> *sigh* Why does kirigami master depend on the not yet released ECM 6.1.0?
>

Likely as Kirigami itself is a Framework - that being said, it seems a bit
weird for the version bumps to be pushed to Frameworks before the release
has been made public (because Craft cannot use them until they're public...)

The real question I have though is why does KTrip depend on Frameworks
master instead of released Frameworks?
Depending on Frameworks master is something applications should avoid
unless it is absolutely necessary.


>
> Regards,
> Ingo


Cheers,
Ben