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

[Ben Cooksley]

On Sun, Apr 28, 2024 at 9:23 PM 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: 1 repo started failing
>
> kconfig:
>  * https://invent.kde.org/frameworks/kconfig/-/pipelines/675292
>   * kconfigcore-kdesktopfiletest fails on Linux
>   * windows fails to compile
>* There have not been changes lately? Qt/ECM regressions?
>

These are not Qt regressions, as Qt is provided by the image and the
Windows image hasn't been rebuilt in weeks. CMake is the same.
They must be regressions within KConfig or ECM.


>
> Cheers,
>   Albert
>

Cheers,
Ben

CI moved to Qt 6.7 for Linux builds

[Ben Cooksley]

Hi all,

I have just flipped the switch that has moved the CI system over to using
Qt 6.7 for Linux builds on our SUSE images.

Should you see any issues with builds failing as a result of packages being
missing in the registry then please submit a merge request to
sysadmin/ci-management to ensure that build dependency is added to our seed
jobs.

I'll leave the Qt 6.6 package registry and container images in place for
another week or so then will schedule them for removal.

As part of this I have also updated the list of projects with Qt 6 only
master branches. Any residual Qt 5 build artifacts the CI system was
holding for those projects have now been purged, which may impact
downstream projects that depend on those projects that are still on Qt 5.

On an adjacent note, i'd also like to schedule removing CI support for
release/23.08 and Plasma/5.27 builds (by purging all their binaries we
currently hold) for the Qt 5.15 series.

While checking however I note that several projects still have activity on
those branches. Can we please confirm whether any further releases are
expected, as i'd prefer to remove anything that isn't being properly
maintained anymore.

Thanks,
Ben

CI moved to Qt 6.7 for Linux builds

[Ben Cooksley]

Hi all,

I have just flipped the switch that has moved the CI system over to using
Qt 6.7 for Linux builds on our SUSE images.

Should you see any issues with builds failing as a result of packages being
missing in the registry then please submit a merge request to
sysadmin/ci-management to ensure that build dependency is added to our seed
jobs.

I'll leave the Qt 6.6 package registry and container images in place for
another week or so then will schedule them for removal.

As part of this I have also updated the list of projects with Qt 6 only
master branches. Any residual Qt 5 build artifacts the CI system was
holding for those projects have now been purged, which may impact
downstream projects that depend on those projects that are still on Qt 5.

On an adjacent note, i'd also like to schedule removing CI support for
release/23.08 and Plasma/5.27 builds (by purging all their binaries we
currently hold) for the Qt 5.15 series.

While checking however I note that several projects still have activity on
those branches. Can we please confirm whether any further releases are
expected, as i'd prefer to remove anything that isn't being properly
maintained anymore.

Thanks,
Ben

CI moved to Qt 6.7 for Linux builds

[Ben Cooksley]

Hi all,

I have just flipped the switch that has moved the CI system over to using
Qt 6.7 for Linux builds on our SUSE images.

Should you see any issues with builds failing as a result of packages being
missing in the registry then please submit a merge request to
sysadmin/ci-management to ensure that build dependency is added to our seed
jobs.

I'll leave the Qt 6.6 package registry and container images in place for
another week or so then will schedule them for removal.

As part of this I have also updated the list of projects with Qt 6 only
master branches. Any residual Qt 5 build artifacts the CI system was
holding for those projects have now been purged, which may impact
downstream projects that depend on those projects that are still on Qt 5.

On an adjacent note, i'd also like to schedule removing CI support for
release/23.08 and Plasma/5.27 builds (by purging all their binaries we
currently hold) for the Qt 5.15 series.

While checking however I note that several projects still have activity on
those branches. Can we please confirm whether any further releases are
expected, as i'd prefer to remove anything that isn't being properly
maintained anymore.

Thanks,
Ben

Please cleanup old forks

[Ben Cooksley]

Hi all,

As part of routine maintenance on Invent (Gitlab) i've been reviewing the
total amount of space currently being consumed by repositories.

At this time, the top 100 largest repositories on Invent (we have 14,000 or
so for context) are consuming around 21% of the total space. It would
therefore be good if we could please clean this up.

To add a bit of context, we currently have around 140GB of repositories,
and a further 30GB of pooled repository data (shared among the canonical
repository and it's forks). Those top 100 repositories currently use 30GB
of space - so as much as all of the pools.

Forks of KDevelop and docs-krita-org feature heavily on the list of large
repositories.

Of particular interest are old forks (created more than 2-3 years ago) as
these are often not participating in Gitlab's mechanism to reduce the disk
space taken by forks (known as pool repositories).

As an additional note: please do not fork a fork, as these forks-of-forks
cannot participate in a pool and must carry a full copy of the upstream
repository data. If you have a situation where a network of forks of forks
has developed please consider options to resolve this.

I know Krita at least has this situation presently with their fork of
various parts of Qt that is being maintained in people's personal
namespaces.

Thanks,
Ben

Please cleanup old forks

[Ben Cooksley]

Hi all,

As part of routine maintenance on Invent (Gitlab) i've been reviewing the
total amount of space currently being consumed by repositories.

At this time, the top 100 largest repositories on Invent (we have 14,000 or
so for context) are consuming around 21% of the total space. It would
therefore be good if we could please clean this up.

To add a bit of context, we currently have around 140GB of repositories,
and a further 30GB of pooled repository data (shared among the canonical
repository and it's forks). Those top 100 repositories currently use 30GB
of space - so as much as all of the pools.

Forks of KDevelop and docs-krita-org feature heavily on the list of large
repositories.

Of particular interest are old forks (created more than 2-3 years ago) as
these are often not participating in Gitlab's mechanism to reduce the disk
space taken by forks (known as pool repositories).

As an additional note: please do not fork a fork, as these forks-of-forks
cannot participate in a pool and must carry a full copy of the upstream
repository data. If you have a situation where a network of forks of forks
has developed please consider options to resolve this.

I know Krita at least has this situation presently with their fork of
various parts of Qt that is being maintained in people's personal
namespaces.

Thanks,
Ben

Re: kdewebkit status

[Ben Cooksley]

On Sun, Apr 21, 2024 at 5:07 AM Ashark  wrote:

> Hello.
>

Hey Andrew,


>
> I have seen a bug that kdewebkit is failing to build (406342). I was
> looking
> why the person was building that module in the first place.
>
> Afaict, this module is not used in any project. Searching in repo-metadata
> by
> "kdewebkit" word, I see it is:
>
> Listed in `dependency-data-kf5-qt5` and in
> `dependency-data-stable-kf5-qt5`,
> without any dependency, and no any other project points to it as a
> dependency.
>
> Listed in `kf5-frameworks.ksb` to be ignored:
> ```
> module-set frameworks
> repository kde-projects
> use-modules frameworks
>
> #tag v5.75.0-rc1
> branch kf5
> ignore-modules kdewebkit kuserfeedback
> end module-set
> ```
>
> and also listed in `kf6-frameworks.ksb` as ignored:
> ```
> module-set frameworks
> repository kde-projects
> use-modules frameworks
> ignore-modules kdelibs4support kdewebkit khtml kjsembed kmediaplayer
> kinit
> kjs kross kdesignerplugin kemoticons kxmlrpcclient
> cmake-options -DBUILD_WITH_QT6=ON
> end module-set
> ```
>
> The projects-invent/frameworks/kdewebkit/metadata.yaml contains the entry
> ```
> repoactive: true
> ```
>
> Maybe this should be marked as `repoactive: false` and removed from ignore-
> modules?
>

The repoactive flag mirrors the status of the repository on Gitlab (whether
it is active or archived).

As Frameworks as a compatibility promise, this repository will need to
continue to limp around unfortunately until KF5 ceases to make releases.


>
> The project readme says that it is removed from kf6.
>
>
>
Cheers,
Ben

Re: Proposal unify back our release schedules

[Ben Cooksley]

On Sat, Apr 20, 2024 at 4:39 AM Kevin Ottens  wrote:

> Hello,
>

Hi all,


>
> Unsurprisingly I'll be pretty much aligned with Luigi, Sune and Volker
> here I
> think. I'll try to add a couple of extra aspects to feed the thinking on
> this
> topic.


> On Friday 19 April 2024 11:04:33 CEST Carl Schwan wrote:
> > I know this might be a controversial idea, but I would like to propose
> > reunify our release schedules. I feel like splitting our releases
> schedules
> > between Frameworks, Plasma and Gear is not working as well as we intended
> > it to be when we split the releases schedules for Plasma 5. This is for
> > multiple reasons:
> >
> > * We end up with 3 different products which are released at different
> times
> > but are connected together. Apps and Plasma both need Framework, Plasma
> > needs some packages from gear like kio-extra, Gear needs some package
> from
> > Plasma like Breeze. Coordinating all these inter-groups dependencies is
> > complex and was one the reason we had to do a megarelease for Plasma 6.
> > Also for the end user, one product is a lot easier to understand.
>
> This is an engineering topic in this case.
>
> And, to me, this is an excellent reason not to reunify release schedules!
> Because what it tells me is that we're still having dependency issues
> which
> need to be solved.
>
> The example you give shows Plasma depending on Gear, this shouldn't
> happen, so
> I'd argue: let's fix that instead.
>

Further cutting these links would be quite beneficial from a CI
perspective, so i'm definitely in favour of this.
Some of the most complicated bits of maintaining the system involve the
interconnections between Gear / Plasma / Independent.

Unfortunately libplasma / kpipewire / plasma-activities will be fairly hard
to avoid if you're targeting certain types of integration.


>
> Aligning the release schedules would only hide such structural issues.
>
> This was one of the main engineering motives to split things up: when it
> wasn't splitted this would stay hidden much longer everyone being comfy
> with
> it.
>
> Now it's creating pain: perfect, that makes the issue obvious, but it
> should
> be addressed not masked.
>
> This is in part what Volker highlighted pointing out this should be less
> of a
> problem with key components being moved to Plasma. Again, if there are
> more,
> let's just address them.
>
> So as pointed out by Sune and Volker: this is a feature (at least in the
> Frameworks case) not a bug.
>
> > * This results in very frequent releases which creates a lot of work for
> > distros and talking with some distro maintainers they seems to agree that
> > having a big releases every 4 months is better than having constantly a
> new
> > minor or major release from either Framework, Gear or Plasma.
>
> This is a downstream relationship topic in this case.
>
> I'm honestly unsure where the problem is though. They could decide to pick
> a
> set of version for the three and focus on that. They don't have and never
> had
> to package every single version of KDE Frameworks.
>
> That being said it indicates to me that we're not good at communicating
> which
> KDE Frameworks version a given Plasma or Gear release targets. More
> coordination and communication here would make sense.


> > * We currently don't have a stable branch for Framework and it takes
> often
> > up to one month for fixes to be deployed. The Framework releases is also
> > not in sync with either Gear nor Plasma while these two modules heavily
> > make use of Framework and contribute to Framework.
>

Changing the Frameworks release cadence away from monthly isn't going to
get fixes out any faster - as if you are using distribution packages it
still has to be packaged.
If anything it will make them take longer as the Frameworks release would
end up being every couple of months instead of monthly? (you can always
build Frameworks locally if you need the fixes now)

I should note that due to a combination of Gitlab configuration and various
projects essentially having a hard dependency on Frameworks master (Plasma,
Dolphin, looking at both of you) the CI system always supplies Frameworks
master regardless of what is being built (the Gitlab configuration is
fixable, but there isn't much motivation to do so when it will just cause
issues and not be used)


>
> This is a QA and testing topic in this case.
>
> The intent is that master is the stable branch (as Luigi pointed out). If
> it's
> not stable in practice we're failing on testing on QA. So extra automated
> tests, more QA and so on should be provided. Yes this is work but it has a
> chance of increasing quality, changing the release cadence won't do
> anything
> about it.


> > * We could have an unified LTS release including more than just Plasma.
> This
> > is something that distros have been asking for some time already because
> > having just Plasma receiving bug-fixes but not Framework nor the apps is
> > not that helpful.
>
> This is a 

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
> > <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 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

Re: Should we stop distributing source tarballs?

[Ben Cooksley]

On Mon, Apr 8, 2024 at 1:55 AM Marc Deop i Argemí  wrote:

> On Saturday, 6 April 2024 18:22:22 CEST Sven Brauch wrote:
> > This is basically a discussion about whether it is less risky to trust
> > the individual developers, or the people with access to the CI signing
> > key. You are trading likeliness of there being one bad actor vs. impact
> > one bad actor can have. It's a matter of personal opinion; there is no
> > right or wrong choice here.
>
> No, it is not.
>
> The key is that the infrastructure creation needs to also be automated.
>
> Once you have the *bootstrap* , you can trust the automation because you
> can
> review and audit it ( to a certain degree, of course, there is nothing
> bullet
> proof).
>
> I have been surprised for years on how the KDE infrastructure is handled
> (so
> many things done manually) but as I am not _in_ I cannot really judge
> because
> I don't know all of the circumstances and context.
>

The trust issue has nothing to do with the infrastructure - problems such
as the XZ compromise cannot be resolved with technological barriers.
The solution to them is social measures.

Having the infrastructure itself hold the key makes it more difficult to
distinguish between the various maintainers publishing the build, and makes
it more likely that someone evil is able to publish a build without anyone
noticing, and also makes it easier for an evil-doer to tamper with tarballs
that are sitting on our infrastructure.

Keeping the key material segregated from the actual release infrastructure
(the key being on the release managers system, and the release
infrastructure being download.kde.org) protects against this.

I appreciate you are trying to protect against evil maintainers/release
managers tampering with tarball contents, however there are other ways of
addressing that.


>
> Best regards
>
> Marc


Cheers,
Ben

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

[Ben Cooksley]

On Mon, Apr 8, 2024 at 9:03 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.
>
> Bad news: 1 repositories is still failing and 1 has started failing
>
> kirigami - 3rd week
>  * https://invent.kde.org/frameworks/kirigami/-/pipelines/649285
>   * Android build fails
>* Something qt related needs a rebuild?
>

This will likely be resolved as part of the upcoming Craft cache rebuild
that is currently being worked on as part of rolling out Qt 6.7.
I'd estimate 1-2 weeks before we start to roll that out, at which point
this should be fixed.


>
>
> kcontacts - NEW
>  * https://invent.kde.org/frameworks/kcontacts/-/pipelines/655262
>   * AddressTest fails on FreeBSD (Same as in master)
>
>
> Cheers,
>   Albert
>

Cheers,
Ben

Re: Should we stop distributing source tarballs?

[Ben Cooksley]

On Sat, Apr 6, 2024 at 4:23 AM Johannes Zarl-Zierl 
wrote:

> Am Freitag, 5. April 2024, 13:45:35 CEST schrieb Carl Schwan:
> > On Friday, April 5, 2024 12:04:28 PM CEST Albert Vaca Cintora wrote:
> > > - Tarballs should only be generated in a reproducible manner using
> > > scripts. Ideally by the CI only.
> > > - We should start to sign tarballs in the CI.
> >
> > I disagree. I want my tarball to be signed with my GPG key stored in my
> > Yubiky and not by a generic KDE key. It should be a proof that I as a
> > maintainer of a project did the release and not someone else. Same with
> the
> > upload to download.kde.org, while this adds some overhead in the
> process, I
> > think it is important that KDE Sysadmins are the one who move the tarball
> > to their final location and do some minimal check (checksum match, it's
> not
> > a random person doing the release, ...).
>
> Signing with a KDE key could have some benefits, though. It's far easier
> for
> distros (or users) to check KDE software against a single, well known key.
>
> On could mitigate the downside that you mentioned by having the script
> check
> the tag signature against a keyring of trusted keys.
>

Please see https://invent.kde.org/sysadmin/release-keyring/ - our process
for validating tarballs for release already includes ensuring the GPG
signatures provided are included in that keyring.
All modern releases of KDE software that come with a GPG signature whose
key is not in that keyring should be rejected.

Developers should also consider adding their keys to Gitlab at
https://invent.kde.org/-/profile/gpg_keys
Following this, your GPG key will be published at
https://invent.kde.org/$username.gpg


>
> Cheers,
>   Johannes


Cheers,
Ben

Re: Should we stop distributing source tarballs?

[Ben Cooksley]

On Sat, Apr 6, 2024 at 1:43 AM Heiko Becker  wrote:

> On Friday, 5 April 2024 12:04:28 CEST, Albert Vaca Cintora wrote:
> > It seems a lot of people feel conservative in favor of tarballs, so
> > maybe I aimed too far. At least I think the discussion brought some
> > interesting points that we can explore further. Some I identified:
> >
> > - The tarballs should contain no changes with respect to git, or
> > minimal changes obviously justifiable in a diff.
>
> Like I wrote earlier in this thread, this should hold true already since
> the translations are synced to git.
>

I would consider any tarball that contains modified files (ie. is not a one
to one representation of the git tag it represents) to be invalid for the
purposes of KDE project releases.
Now that translations are synced into our Git repositories there is no
reason why we should have differences.


>
> > - Tarballs should only be generated in a reproducible manner using
> > scripts. Ideally by the CI only.
> > - We should start to sign tarballs in the CI.
>
> The scripts already exists for the bundles and users of releasme. Letting
> the CI create tarballs seems indeed like a good way to reduce
> possibilities
> of human tampering.
> With regard to signing: At first I thought that it means something that
> the
> person responsible for the release is also signing the tarballs. But maybe
> there could even be two signatures in the future, one by CI and one by the
> release person (although that would probably mean a few challenges for the
> tooling).
>
> > - We should start to sign commits and tags. Git recently made this
> > super easy by allowing signing with the ssh keys that we all are
> > already using to push things, so no excuses for not enabling this.
>
> We already sign commits for the 3 release bundles and users of relaseme.
>
> But I'm surprised about the total absence of social aspects of the xz
> incidence during this discussion.
> Admittedly we fall back to community maintenance if a maintainer becomes
> unavailable, so the exact xz scenario doesn't seem likely. But there are
> probably a few projects on the fringes. Do we have safeguards in place if
> a
> nefarious person tries to steps up as maintainer? Can we do something to
> help projects, which are struggling?
>

This is really the key issue at hand.

If you look at the timeline in question, the malicious actor(s) in the XZ
incident moved slowly, starting as a general contributor, accruing trust
and eventually made their way up to getting maintainer access and the
ability to make releases.

Even with the various checks and balances we have in place around granting
developer accounts, who gets permissions to update our websites, requiring
people to go through tickets to publish releases on download.kde.org, etc.
a similar kind of attack played out over a long enough period of time is
still one that none of our technological protections would be able to stop
- as people who have been long term contributors and have worked their way
up to being a maintainer will tend to obtain the necessary permission or
trust of those with permissions.

Such attacks however will always fail when confronted with enough sunlight
however, something that Linus' law of "with enough eyes all bugs are
shallow" covers fairly well.
To adequately protect ourselves we need to ensure that projects that only
have 1 or 2 maintainers, as well as those that are "community maintained"
are monitored (historically a function that kde-commits@ has filled).

There is also something to be said that for larger projects such as ours
(ie. the ones who are targets) that we should also be keeping an eye on the
smaller libraries that we depend on - as while we may be too hard to attack
it is much easier to attack those we depend on who don't have the same
resources we do (which is basically what happened with XZ/OpenSSH).

These would be projects with just one or two maintainers with fairly
infrequent activity, and that are often located in a maintainers personal
namespace on GitHub or Gitlab.com, or on personal hosting of their own.
Examples of projects in this sort of space would be the likes of QtKeychain
or kColorPicker (just picking two that immediately spring to mind), but
there is no reason that shouldn't also cover non-Qt libraries. There are
probably a couple of different options we could explore in this space as to
how to best accomplish this.

We should also consider whether it is acceptable for us to depend on any
project that uses a build system that is either bespoke or not modern (ie.
autotools, self-written bash scripts, etc) - as that was a significant
contributor to how the XZ attack was able to be perpetrated. My vote would
be that it is not acceptable and we should be strongly pushing any project
that does not use a modern build system to migrate to one that is.


>
> Regards,
> Heiko
>

Cheers,
Ben

Re: Should we stop distributing source tarballs?

[Ben Cooksley]

On Thu, Apr 4, 2024 at 10:48 PM Sune Vuorela  wrote:

> On 2024-04-03, Albert Vaca Cintora  wrote:
> > What's the advantage of providing tarballs?
>
> I do think there is an advantage in being able to verify that the soure
> tarball is the same across distributions. Using a checksum on the
> tarball is an easy way of doing it. Different git invocations for git
> archive, different tar options and so on can create different checksums
> for the same content.
>

For those wondering, for all content served by download.kde.org and
files.kde.org, you can fetch a sha256 hash of the file in question by just
appending ".sha256" to the URL in question.
See
https://download.kde.org/stable/release-service/24.02.1/src/okular-24.02.1.tar.xz.sha256
for instance.

These won't show up in the file listings, and are not files that are
provided to mirrors - they are provided by our mirror management system
(MIrrorbits) directly.

As an additional aside - we don't currently GPG sign our Git tags, so there
is nothing validating that the person who made the release is actually the
person whose name is on it.
With GPG signatures we can at least validate who owns the key.


>
> I do also think it is nice if we get someone else to verify that the
> tarball we ship actually matches the tag. I think some people in
> distributions have already started looking into verifying that.
>

Hopefully they'll be gentle with tooling that does this?


>
> Also, git tags can be moved.
>
> /Sune
>
>
Cheers,
Ben

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

[Ben Cooksley]

On Wed, Apr 3, 2024 at 11:41 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 1 repository has started
> failing
>
> kirigami-gallery - 2nd week
>  * https://invent.kde.org/sdk/kirigami-gallery/-/pipelines/650570
>   * Android build fails
>* Similar problem to the one in kirigami being discussed in the
> frameworks
> mailing list
>

I suspect we're up for a cache rebuild to resolve this one, although once
again there is debate about how functional / supported Qt 5 Android builds
are anymore.


>
>
>
> umbrello - 2nd week
>  * https://invent.kde.org/sdk/umbrello/-/pipelines/650565
>   * craft_windows_qt515_x86_64 fails
>* Same as in the master report, something is up with qtwebengine?
>

I had a quick look and couldn't see any reason why this is occurring.
Nowhere is the ignore for WebEngine set except for MacOS, and this is a
Windows MSVC build so it should be fine.

This will be one for #kde-craft:kde.org I fear.


>
>
> kitinerary - NEW
>  * https://invent.kde.org/pim/kitinerary/-/pipelines/650569
>   * extractortest fails in FreeBSD
>

Likely fallout of the image rebuild, i'll need to work with Tobias on
straightening this out.


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

signon-kwallet-extension

[Ben Cooksley]

Hi all,

Due to recent updates in SUSE around signond, i've just had to remove
signond-libs-devel from our SUSE Qt 5.15 images.

This is due to signond now being built with Qt 6 - and therefore being
incompatible with Qt 5.

Looking in signon-kwallet-extension though I see it is still Qt 5 code that
is unported.

It will therefore lose CI coverage support on LInux from today onward until
it is ported to Qt 6.

Cheers,
Ben

Re: AppStream Metadata with our releases

[Ben Cooksley]

On Wed, Mar 27, 2024 at 5:40 AM Volker Krause  wrote:

> On Dienstag, 26. März 2024 08:59:29 CET Heiko Becker wrote:
> > On Monday, 25 March 2024 23:23:01 CET, Albert Astals Cid wrote:
> > > El dissabte, 23 de març de 2024, a les 21:06:46 (CET), Julius Künzel va
> > >
> > > escriure:
> > >> 22.03.2024 17:22:33 Albert Astals Cid : ...
> > >
> > > It is some extra work (not a lot, but some).
> > >
> > > You're asking for the workflow of creating to be releases to be
> changed by
> > > creating the entry in the file earlier, that alone is a bit of work,
> but
> > > it
> > >
> > > has several other consequences:
> > >  * https://apps.kde.org/okular/ shows releases from the appstream
> file (i
> > >
> > > think) meaning that the code should learn to ignore releases in the
> > > future.
> > > Arguably we would need also now, but given the data is added
> > > just a few days
> > > before the actual release i think users can understand "this release
> will
> > > happen soon)" compared to a thing one month in the future
> > >
> > >  * What happens if we have to change the release date or release
> version
> > >
> > > number (hasn't happened in a good while, but wouldn't be a bad thing to
> > > prepare for it). We would need to update the string or date of an
> existing
> > > entry, as far as I know we don't have tooling for that (because we only
> > > add
> > > the data to the file when we're almost sure abiyt it).
> >
> > In addition I'm a litte bit wary of conflicts when cherry-picking the
> > appstream changes between branches, which the script does after
> > incrementing the version. I saw at least conflicts in itinerary's
> releases
> > notes and e.g. kdeconnect's or okular's windows releases in the past,
> which
> > isn't that much of a problem but it could become one with the 245 modules
> > of gear (to be fair not all have appstream metadata (yet)).
>
> Sorry about that! I try to keep both branches in sync usually, if there is
> anything I can do/do differently to not impact your work I'm happy to do
> that
> of course.
>
> > Otherwise I'd just miss the opportunity to trigger a CI build for
> > everything again shortly before the release, but I'd guess that's easy to
> > get over.
>
> Albert seems to have an alternative way using API (?) for the weekly build
> status reports, I guess that could be reused/combined somehow?
>

Please see
https://docs.gitlab.com/ee/api/pipelines.html#create-a-new-pipeline
I imagine he uses
https://docs.gitlab.com/ee/api/pipelines.html#get-the-latest-pipeline to
fetch the outcome of that.

Note that the above API is not suitable for building a public dashboard due
to the number of queries we would need, but it is fine for one off runs
like what Albert does.


>
> Regards,
> Volker


Cheers,
Ben

Re: KDE Frameworks with failing CI (kf5) (24 March 2024)

[Ben Cooksley]

On Wed, Mar 27, 2024 at 5:55 AM Volker Krause  wrote:

> On Dienstag, 26. März 2024 00:42:53 CET Albert Astals Cid wrote:
> > El dilluns, 25 de març de 2024, a les 18:03:27 (CET), Volker Krause va
> >
> > escriure:
> > > On Sonntag, 24. März 2024 23:14:12 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.
> > > >
> > > > Bad news: 2 repositories have started failing
> > > >
> > > > kirigami - NEW
> > > >
> > > >  * https://invent.kde.org/frameworks/kirigami/-/jobs/1679118
> > > >
> > > >   * Android build fails
> > > >
> > > >* Something qt related needs a rebuild?
> > >
> > > Yep, looks like a version mix due to the patch collection rebase.
> >
> > But why has this happened? I mean how is it that some Qt has different
> than
> > some other Qt? Was there a rebuild of Android Qt while i was doing the
> > rebase?
> >
> > If I understand that right there's a QtSvg is 5.15.13 but QtWidgets is
> only
> > 5.15.12?
>
> Not sure what caused it specifically here, but this happens as soon as
> anything
> triggers a rebuild of a part of Qt for whatever reason. That part is then
> taken from the kde/5.15 head, which is newer than the rest of Qt in the
> cache.
>
> The effect used to spread/worsen over time as more things in the cache
> become
> outdated (not sure if that got better or worse with the significantly
> reduced
> Qt5-related activity nowadays).
>
> > > I'm wondering how we want to proceed here longer term, as this will
> > > continue to need active maintenance while most of our Android apps have
> > > meanwhile moved to Qt 6.
> > >
> > > Pin the Qt version in Craft to a fixed revision? Drop Android KF5 CI
> > > builds? Find volunteers to do the work of keeping this running/working?
> >
> > If we're saying Kirigami works on Android ideally we should keep a CI.
>
> Pinning the Qt5 version might be a good compromise then? Keeping Kirigami
> working in a fixed environment should be fine, but dealing with the
> movement in
> Qt, Android and Craft for one major version is hard enough already.
>

This issue has existed for a while now as you've pointed out.

The only real fix is for us to fully rebuild the Craft cache each time the
KDE Qt 5 Patch Collection is rebased.
Without the existence of version specific stable branches of the patch
collection for us to point Craft to, that is the best we'll be able to do
unfortunately, as currently we've basically got Craft pointed at a moving
target.

Alternatively, we can move Qt 5 support in Craft to an LTS branch which
should ensure the amount of movement in the blueprints (which triggers the
rebuilds of parts of Qt in the cache) is minimised (keeping the cache
valid, even if outdated)


>
> Regards,
> Volker
>

Cheers,
Ben

Re: KDE Gear projects with failing CI (master) (12 March 2024)

[Ben Cooksley]

On Wed, Mar 13, 2024 at 12:12 PM 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: 6 repositories got fixed
>
> Bad news: 2 repository still failing and 7 new repositories failing this
> week
>
>
> filelight - 2nd week
>  * https://invent.kde.org/utilities/filelight/-/pipelines/628855
>   * craft fails
>
>
> klickety - 2nd week
>  * https://invent.kde.org/games/klickety/-/pipelines/628858
>   * appstreamtest fails


Hm, I thought I had fixed all the Appstream failures.

Anyway, this is fixed now.


>
>
>
> kalgebra - NEW
>  * https://invent.kde.org/education/kalgebra/-/pipelines/628851
>   * flatpak fails, needs libplasma
>
>
> kig - NEW
>  * https://invent.kde.org/education/kig/-/pipelines/628852
>   * craft fails
>
>
> kdenlive - NEW
>  * https://invent.kde.org/multimedia/kdenlive/-/pipelines/628926
>   * Qt6 code fails to compile
>
>
> akregator - NEW
>  * https://invent.kde.org/pim/akregator/-/pipelines/628861
>   * appstreamtest fails


Fixed as well. No idea how this passed last week given nothing has changed
here?


>
>
>
> neochat - NEW
>  * https://invent.kde.org/network/neochat/-/pipelines/628957
>   * craft fails
>

Likely caused by libtiff being present on the system when the cache was
built, but not being marked as a dependency of QtWebEngine.
Craft folks, will adding libtiff as a dependency of QtWebEngine without
bumping the patch version cause any issues? (that should fix this)


>
>
> mimetreeparser - NEW
>  * https://invent.kde.org/pim/mimetreeparser/-/pipelines/628865
>   * core-cryptohelpertest fails
>
>
Don't understand how that could fail out of the blue...


>
>
> francis - NEW
>  * https://invent.kde.org/utilities/francis/-/pipelines/628866
>   * reuse fails
>

Fixed by Carl in
https://invent.kde.org/utilities/francis/-/commit/a3749a7f74ed2bdffeb3b4bc17835ae7ccd6fa64


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

Re: KDE Gear projects with failing CI (release/24.02) (12 March 2024)

[Ben Cooksley]

On Wed, Mar 13, 2024 at 12:34 PM 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.
>
>
> VERY BAD NEWS:
>  * Cantor made it to its 4th week with FreeBSD tests failing
>   * I have disabled them
> *
> https://invent.kde.org/education/cantor/-/commit/5b2a8285e2f6ecac28f4ae07c602b9b8f8c7f7fa
>
> Good News: 6 failing repositories from previous report got fixed
>
> Bad news: 2 repositories are still failing and 2 new repositories started
> failing
>
>
> kimap - 3rd week
>  * https://invent.kde.org/pim/kimap/-/pipelines/628890
>   * testsession fails on FreeBSD
>
>
> neochat - 3rd week
>  * https://invent.kde.org/network/neochat/-/pipelines/628898
>   * craft build fails
>
>
> kdenlive - NEW
>  * https://invent.kde.org/multimedia/kdenlive/-/pipelines/628930
>   * Qt6 code fails to compile
>
>
> akregator - NEW
>  * https://invent.kde.org/pim/akregator/-/pipelines/628861
>   * appstreamtest fails


No idea why this has suddenly shown up as a failure.
Appstream makes no sense sometimes - either way, should be fixed now.


>
>
>
>
> Cheers,
>   Albert
>

Cheers,
Ben

Re: KDE Frameworks with failing CI (master) (10 March 2024)

[Ben Cooksley]

On Mon, Mar 11, 2024 at 12:46 PM 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: 1 repository is still failing and 1 new has started failing
>
>
> kimageformats - 3rd week
>  * https://invent.kde.org/frameworks/kimageformats/-/pipelines/627271
>   * kimageformats-read-xcf fails in Linux CI
>* https://invent.kde.org/frameworks/kimageformats/-/merge_requests/211
> fixes it but then breaks the BSD builder (because it is on an older Qt)
> Can we
> update Qt in the BSD builder to 6.6.2?
>

Please file a ticket for that update.


>
>
> kpackage - NEW
>  * https://invent.kde.org/frameworks/kpackage/-/pipelines/627276
>   * appstream check fails
>

It would appear that this will require changes to the KPackage format to
ensure that we allow (require?) plugins to specify a homepage to comply
with Appstream requirements.


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

Linking to Gitlab CD build results

[Ben Cooksley]

Hi all,

For those that have been experimenting with the Craft Continuous Delivery
jobs on Gitlab, one of the many questions we've been receiving is how to
best link to those from your websites.

I'm happy to advise that going forward build results will now be published
for release branches on mainline repositories at
https://cdn.kde.org/ci-builds/. This location is fully scalable and can be
freely linked to for the purpose of offering downloads of nightly builds of
your projects.

One key thing to note is that because Craft includes an incrementing number
in the filename, you should link to the appropriate folder not the artifact
directly. Additionally, please note that any slashes in branch names will
be converted into dashes as part of the publishing process.

Because this service is only available for release branches and master on
mainline repositories, builds from personal forks, or from work branches on
our mainline repositories will not be published here.

Please note that this is not a home for permanent release builds. On making
a release projects should download the latest build results (either from
Gitlab directly or from cdn.kde.org/ci-builds/), validate them and then
release them the same as any other tarball artifact. Older builds may be
removed from cdn.kde.org/ci-builds/ on a periodic basis.

With regards to Android and Flatpak, those will not be covered by those
service. For Android builds, usage of our F-Droid repositories (at
https://cdn.kde.org/android/) is recommended, while for Flatpak it is
recommended to make use of the Flatpak repositories we publish at
https://cdn.kde.org/flatpak/. These mechanisms are being preferred for
these two as they are native to those two platforms (while Linux appimages,
Windows installers and macOS images do not have those delivery mechanisms
available).

Thanks,
Ben

Re: KDE Gear projects with failing CI (release/24.02) (5 March 2024)

[Ben Cooksley]

On Wed, Mar 6, 2024 at 1:22 PM 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 6 new repositories started
> failing
>
>
> cantor - 3rd week
>  * https://invent.kde.org/education/cantor/-/pipelines/622239
>   * FreeBSD tests fail
>
>
> kimap - 2nd week
>  * https://invent.kde.org/pim/kimap/-/pipelines/622338
>   * testsession fails on FreeBSD
>
>
> neochat - 2nd week
>  * https://invent.kde.org/network/neochat/-/pipelines/622783
>   * craft builds fail
>
>
> kwave - 1st week
>  * https://invent.kde.org/multimedia/kwave/-/pipelines/622278
>   * Linux build fails, complains that neither rsvg nor convert are
> installed
>

KWave is now incompatible with building on OpenSUSE i'm afraid, as they
don't provide rsvg as an executable under the "rsvg" name.
The best they can do is rsvg-convert (which is hopefully the same thing).

I suspect they removed SVG support from ImageMagick (likely for security
reasons).


>
>
> kdebugsettings - 1st week
>  * https://invent.kde.org/utilities/kdebugsettings/-/pipelines/622265
>   * appstreamtest fails
>

Fix from master has now been cherry picked.


>
>
> pim-sieve-editor - 1st week
>  * https://invent.kde.org/pim/pim-sieve-editor/-/pipelines/622340
>   * appstreamtest fails


Justin fixed this but it exposed a Flatpak failure.
That fix has been cherry picked as well now.


>
>
>
> kbackup - 1st week
>  * https://invent.kde.org/utilities/kbackup/-/pipelines/622344
>   * appstreamtest fails


Should be fixed now along with master.


>
>
>
> kweather - 1st week
>  * https://invent.kde.org/utilities/kweather/-/pipelines/622781
>   * flatpak fails, needs libplasma
>
>
> kclock - 1st week
>  * https://invent.kde.org/utilities/kclock/-/pipelines/622372
>   * The appstream job didn't get a runner, should this be removed?
>
>
> Cheers,
>   Albert
>

Cheers,
Ben

Re: KDIff3 Craft CI for MacOS broken

[Ben Cooksley]

On Tue, Feb 27, 2024 at 1:12 PM Michael Reeves  wrote:

> Does anyone have insight as to why this is happeing:
>
>
> /Resources/qml/org/kde/i18n/localeData/libki18nlocaledataqmlplugin.dylib'] 
> succeeded with exit code 0
> Library dependency 
> '/Users/gitlab/ws/builds/GZwHuM5x/0/sdk/kdiff3/macos-arm-clang/build/extragear/kdiff3/archive/Applications/KDE/kdiff3.app/Contents/Frameworks/libKF6I18nLocaleData.6.dylib'
>  does not exist
> /Users/gitlab/ws/builds/GZwHuM5x/0/sdk/kdiff3/macos-arm-clang/build/extragear/kdiff3/archive/Applications/KDE/kdiff3.app/Contents/Resources/qml/org/kde/i18n/localeData/libki18nlocaledataqmlplugin.dylib:
>  Failed to add library dependency 
> '/Users/gitlab/ws/builds/GZwHuM5x/0/sdk/kdiff3/macos-arm-clang/build/extragear/kdiff3/archive/Applications/KDE/kdiff3.app/Contents/Frameworks/libKF6I18nLocaleData.6.dylib'
>  into bundle
> Action: package for extragear/kdiff3:1.11 FAILED
>
>
Hi Michael,

This is extremely bad timing to be trying to do anything in the application
packaging space, as the constant version bumping within Frameworks and
elsewhere is causing carnage and breakage just about everywhere.
See Flatpak for instance.

I'd suggest waiting a good week or so before trying again, as we will need
to get Craft updated to the 6.0 release made public yesterday.

Have a sneaking suspicion that this will be symlink related though.

Regards,
Ben

Re: KDE Gear projects with failing CI (release/24.02) (28 February 2024)

[Ben Cooksley]

On Wed, Feb 28, 2024 at 9:45 PM Sune Vuorela  wrote:

> On 2024-02-28, Albert Astals Cid  wrote:
> > konversation - 1st week
> >  * https://invent.kde.org/network/konversation/-/pipelines/616933
> >   * cmake fails to find dbus on Linux CI
>
> This seems like intentional sillyness from the konversation developers.
> Let's fail at build time for runtime components that are used in fringe
> usecases.
> My suggestion is to revert the offending commits.
>

Will be fixed following
https://invent.kde.org/sysadmin/ci-images/-/commit/dd1c968e2d16bd96bf091365f34afdee12b39e42
and the corresponding image builds.


>
> /Sune
>
>
Cheers,
Ben

Re: KDE Frameworks with failing CI (master) (25 February 2024)

[Ben Cooksley]

On Mon, Feb 26, 2024 at 11:18 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 has been fixed
>
> Bad news: 3 NEW repository are failing
>
>
> extra-cmake-modules - NEW
>  *
> https://invent.kde.org/frameworks/extra-cmake-modules/-/pipelines/615155
>   * "This job is stuck because the project doesn't have any runners online
> assigned to it." on the "docs" job
>

This job is no longer needed following improvements to the process that
generates api.kde.org so i've removed the job from both KF6 (master) and
KF5.


>
>
> kimageformats - NEW
>  * https://invent.kde.org/frameworks/kimageformats/-/pipelines/615158
>   * kimageformats-read-xcf fails in Linux CI
>
>
> kuserfeedback - NEW
>  * https://invent.kde.org/frameworks/kuserfeedback/-/pipelines/615161
>   * flatpak fails for versioning (why does this even have a flatpak?
> that's
> the user case for a kuserfeedback flatpak?)
>
>
> Cheers,
>   Albert
>

Cheers,
Ben

Re: Post-MegaRelease projects

[Ben Cooksley]

On Sat, Feb 24, 2024 at 11:35 PM Konstantin Kharlamov 
wrote:

> On Sat, 2024-02-24 at 23:07 +1300, Ben Cooksley wrote:
>
> On Sat, Feb 24, 2024 at 10:27 PM Konstantin Kharlamov 
> wrote:
>
> On Sat, 2024-02-24 at 22:16 +1300, Ben Cooksley wrote:
>
> On Sat, Feb 24, 2024 at 8:37 PM Konstantin Kharlamov 
> wrote:
>
> On Sat, 2024-02-24 at 16:31 +1300, Ben Cooksley wrote:
>
> On Fri, Feb 23, 2024 at 11:12 PM Sune Vuorela  wrote:
>
> On 2024-02-22, Nate Graham  wrote:
> > I've started pondering post-megarelease projects. We've spent so long on
> > porting and bugfixing that I think it might be useful to shift gears to
> > feature work, and I'd like to brainstorm potential large-scale projects
> > and gauge the level of interest in putting resources into them soon.
>
> A bit more from the devops end that I'd love to see people tackle:
>
>  - Ensure frameworks and app unit tests interacting with windows can run
>on Windows.
>More details: The following fails on our windows CI
>https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp
>I find it weird that we are spending resources on putting things in
>the windows store and making apps available on windows, but we can't
>actually have passing tests in our CI.
>
>
> This unfortunately will not be easy to solve.
>
> One of the key things that we've learned out of doing CI, as has been
> showcased by FreeBSD in particular, is that the builders need to be
> ephemeral - that is only around for the build in question that is being run.
> We're currently accomplishing this by using containers - via Podman (for
> Linux/Android/FreeBSD) and Docker (for Windows).
>
> Containers also offer us the advantage of allowing people to easily
> reproduce the CI environment on their local system without too much trouble.
>
> For Windows however, Microsoft has limited the container stack to not
> allow anything GUI related to work. The underlying libraries may be there,
> but the equivalent display server components are not operational.
>
> To complicate things further, on Windows certain permissions are
> restricted to the interactive console and are not possible to do as either
> a scheduled task or as a system service.
> Usage of existing Windows automation frameworks such as Powershell
> Remoting or SSH will therefore not work if we want things to perfectly
> replicate a end user environment - because those will run the command(s) as
> part of a non-interactive session (even if the user we connect as is the
> same one logged in on the desktop console).
>
>
> Idk if it's a silly question, but… If Windows native containers have so
> many restrictions, why not just use Linux containers with WINE inside?
>
>
> Because Wine is not Windows either, and there could be subtle differences
> in how things run / interact with the system.
>
>
> Fair point, no sw is bugless. Although, from my shallow experience WINE
> seems to have an excellent test suite. I remember reporting a regression
> once, which turned out to be due to some obscure surfaces manipulation by
> an old Heroes Ⅲ game. WINE devs not only quickly fixed that, but they also
> added tests for that case, so I'd presume such regression is just not gonna
> happen anymore.
>
> Plus some of our software would like to test certain system level
> infrastructure (like say KDE Connect).
>
>
> Out of curiosity, what does this infrastructure include? I thought KDE
> connect only uses network sockets and system tray.
>
>
> No idea, I saw their commentary on debugging issues they were having in
> their unit tests in #kde-devel.
> Those issues were due to a lack of permissions, specifically around the
> interactive console - that is how I know some of our tests need those
> additional permissions and why running as a scheduled task / system service
> will not be sufficient for "fully working" CI tests on Windows.
>
>
> Sorry, it seems there's some misunderstanding… Judging by what you say you
> seem to be referring to the restrictions that Windows containers have on
> Windows. But that was the point that started this thread, to which I
> replied that running Linux containers with WINE might be a solution 
>

What i'm referring to here is that KDE Connect interacts with various
components of the system in order to do what it does.
See for instance the ability to share Notifications between devices, or
ability to act as a presenter device.

That requires accessing various system level APIs which WINE very well may
not support - and we wouldn't support a scenario of using it under WINE
because there is a native Linux version already.


>
> Plus, we have to have native Windows to compile things anyway

Re: Post-MegaRelease projects

[Ben Cooksley]

On Sat, Feb 24, 2024 at 10:27 PM Konstantin Kharlamov 
wrote:

> On Sat, 2024-02-24 at 22:16 +1300, Ben Cooksley wrote:
>
> On Sat, Feb 24, 2024 at 8:37 PM Konstantin Kharlamov 
> wrote:
>
> On Sat, 2024-02-24 at 16:31 +1300, Ben Cooksley wrote:
>
> On Fri, Feb 23, 2024 at 11:12 PM Sune Vuorela  wrote:
>
> On 2024-02-22, Nate Graham  wrote:
> > I've started pondering post-megarelease projects. We've spent so long on
> > porting and bugfixing that I think it might be useful to shift gears to
> > feature work, and I'd like to brainstorm potential large-scale projects
> > and gauge the level of interest in putting resources into them soon.
>
> A bit more from the devops end that I'd love to see people tackle:
>
>  - Ensure frameworks and app unit tests interacting with windows can run
>on Windows.
>More details: The following fails on our windows CI
>https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp
>I find it weird that we are spending resources on putting things in
>the windows store and making apps available on windows, but we can't
>actually have passing tests in our CI.
>
>
> This unfortunately will not be easy to solve.
>
> One of the key things that we've learned out of doing CI, as has been
> showcased by FreeBSD in particular, is that the builders need to be
> ephemeral - that is only around for the build in question that is being run.
> We're currently accomplishing this by using containers - via Podman (for
> Linux/Android/FreeBSD) and Docker (for Windows).
>
> Containers also offer us the advantage of allowing people to easily
> reproduce the CI environment on their local system without too much trouble.
>
> For Windows however, Microsoft has limited the container stack to not
> allow anything GUI related to work. The underlying libraries may be there,
> but the equivalent display server components are not operational.
>
> To complicate things further, on Windows certain permissions are
> restricted to the interactive console and are not possible to do as either
> a scheduled task or as a system service.
> Usage of existing Windows automation frameworks such as Powershell
> Remoting or SSH will therefore not work if we want things to perfectly
> replicate a end user environment - because those will run the command(s) as
> part of a non-interactive session (even if the user we connect as is the
> same one logged in on the desktop console).
>
>
> Idk if it's a silly question, but… If Windows native containers have so
> many restrictions, why not just use Linux containers with WINE inside?
>
>
> Because Wine is not Windows either, and there could be subtle differences
> in how things run / interact with the system.
> Plus some of our software would like to test certain system level
> infrastructure (like say KDE Connect).
>
>
> Out of curiosity, what does this infrastructure include? I thought KDE
> connect only uses network sockets and system tray.
>

No idea, I saw their commentary on debugging issues they were having in
their unit tests in #kde-devel.
Those issues were due to a lack of permissions, specifically around the
interactive console - that is how I know some of our tests need those
additional permissions and why running as a scheduled task / system service
will not be sufficient for "fully working" CI tests on Windows.


>
> Plus, we have to have native Windows to compile things anyway as we need
> to use MSVC (otherwise you have no Qt Web Engine support, as that cannot be
> built with MingW)
>
>
> But I presume it can be built with Clang? In particular, Google Chrome on
> Windows is being built with Clang — and Web Engine is basically a fork of
> Chromium.
>

Qt 6 as a whole does not list Clang as a supported compiler - see
https://doc.qt.io/qt-6/supported-platforms.html

Given Windows is a bit strange in the first place, i'd be quite reluctant
to step outside of what they list as supported.


>
> (and you cannot really mix MingW / MSVC binaries due to incompatible
> compiler ABIs for C++ code)
>
>
> Well, if for testing purposes Qt was pre-built with Clang, I guess there
> won't be any ABI issues.
>

Would require that everything else we have is rebuilt, and that all
downstream users of our Craft cache also switch to Clang.
Note that like most open source projects, we don't know the full extent to
which Craft is used outside of our own project.

Historically we have seen through Microsoft provided data that dependencies
which we built and signed have shown up in surprising places (such as
Snoretoast - which was used by something Node.js based at one point or
another I believe)

Cheers,
Ben

Re: Post-MegaRelease projects

[Ben Cooksley]

On Sat, Feb 24, 2024 at 9:21 PM Volker Krause  wrote:

> On Saturday, 24 February 2024 04:31:49 CET Ben Cooksley wrote:
> > On Fri, Feb 23, 2024 at 11:12 PM Sune Vuorela  wrote:
> > > On 2024-02-22, Nate Graham  wrote:
> > > > I've started pondering post-megarelease projects. We've spent so
> long on
> > > > porting and bugfixing that I think it might be useful to shift gears
> to
> > > > feature work, and I'd like to brainstorm potential large-scale
> projects
> > > > and gauge the level of interest in putting resources into them soon.
> > >
> > > A bit more from the devops end that I'd love to see people tackle:
> > >  - Ensure frameworks and app unit tests interacting with windows can
> run
> > >
> > >on Windows.
> > >More details: The following fails on our windows CI
> > >
> https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp
> > >I find it weird that we are spending resources on putting things in
> > >the windows store and making apps available on windows, but we can't
> > >actually have passing tests in our CI.
> >
> > This unfortunately will not be easy to solve.
>
> And that's fine, we are in dreaming territory here anyway :)
>
> > One of the key things that we've learned out of doing CI, as has been
> > showcased by FreeBSD in particular, is that the builders need to be
> > ephemeral - that is only around for the build in question that is being
> run.
> > We're currently accomplishing this by using containers - via Podman (for
> > Linux/Android/FreeBSD) and Docker (for Windows).
> >
> > Containers also offer us the advantage of allowing people to easily
> > reproduce the CI environment on their local system without too much
> trouble.
> >
> > For Windows however, Microsoft has limited the container stack to not
> allow
> > anything GUI related to work. The underlying libraries may be there, but
> > the equivalent display server components are not operational.
> >
> > To complicate things further, on Windows certain permissions are
> restricted
> > to the interactive console and are not possible to do as either a
> scheduled
> > task or as a system service.
> > Usage of existing Windows automation frameworks such as Powershell
> Remoting
> > or SSH will therefore not work if we want things to perfectly replicate a
> > end user environment - because those will run the command(s) as part of a
> > non-interactive session (even if the user we connect as is the same one
> > logged in on the desktop console).
> >
> > Resolving this will therefore not only require running full sized Windows
> > VMs (on an ephemeral basis to avoid the recently resolved issues that
> used
> > to plague FreeBSD), but would also need the VM to automatically login and
> > spawn an agent as part of the interactive desktop session that we would
> > connect to in order to run the CI tests.
> >
> > The spawning of a VM would require refactoring the setup of our poor CI
> > workers (again - after they were only just recently completely rebuilt to
> > allow the transition to Podman to fix flatpak-builder) to make use of
> > something like:
> > -
> >
> https://forum.gitlab.com/t/custom-executor-into-windows-vm-using-linux-kvm-l
> > ibvirt/72713/5 -
> > https://docs.gitlab.com/runner/executors/custom_examples/libvirt.html
> >
> > We would still have to write the agent that receives our commands
> > (something like
> > https://gist.github.com/cschwede/3e2c025408ab4af531651098331cce45 maybe)
> >
> > We would still have to solve the issue of how to share disk images among
> > our nodes so they were built (ideally would be able to use Gitlab's
> > Container Registry for this, which is something Tart can do - Tart being
> a
> > virtualisation management utility for ARM based Macs), as well as
> > automating the installation of the various OSes we need to run this way.
> > See
> >
> https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/autom
> > ate-windows-setup?view=windows-11 for some notes on that for Windows.
> >
> > The big downside to all of that of course is that the worker nodes would
> > take longer to startup, and it would make sharing build artifacts much
> more
> > difficult and/or less efficient.
> >
> > >  - Find a way to run unit tests on android CI.
> >
> > Likewise, this is very non-trivial - from my understanding our tooling
> > currently for building Android software is centered around it all b

Re: Post-MegaRelease projects

[Ben Cooksley]

On Sat, Feb 24, 2024 at 8:37 PM Konstantin Kharlamov 
wrote:

> On Sat, 2024-02-24 at 16:31 +1300, Ben Cooksley wrote:
>
> On Fri, Feb 23, 2024 at 11:12 PM Sune Vuorela  wrote:
>
> On 2024-02-22, Nate Graham  wrote:
> > I've started pondering post-megarelease projects. We've spent so long on
> > porting and bugfixing that I think it might be useful to shift gears to
> > feature work, and I'd like to brainstorm potential large-scale projects
> > and gauge the level of interest in putting resources into them soon.
>
> A bit more from the devops end that I'd love to see people tackle:
>
>  - Ensure frameworks and app unit tests interacting with windows can run
>on Windows.
>More details: The following fails on our windows CI
>https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp
>I find it weird that we are spending resources on putting things in
>the windows store and making apps available on windows, but we can't
>actually have passing tests in our CI.
>
>
> This unfortunately will not be easy to solve.
>
> One of the key things that we've learned out of doing CI, as has been
> showcased by FreeBSD in particular, is that the builders need to be
> ephemeral - that is only around for the build in question that is being run.
> We're currently accomplishing this by using containers - via Podman (for
> Linux/Android/FreeBSD) and Docker (for Windows).
>
> Containers also offer us the advantage of allowing people to easily
> reproduce the CI environment on their local system without too much trouble.
>
> For Windows however, Microsoft has limited the container stack to not
> allow anything GUI related to work. The underlying libraries may be there,
> but the equivalent display server components are not operational.
>
> To complicate things further, on Windows certain permissions are
> restricted to the interactive console and are not possible to do as either
> a scheduled task or as a system service.
> Usage of existing Windows automation frameworks such as Powershell
> Remoting or SSH will therefore not work if we want things to perfectly
> replicate a end user environment - because those will run the command(s) as
> part of a non-interactive session (even if the user we connect as is the
> same one logged in on the desktop console).
>
>
> Idk if it's a silly question, but… If Windows native containers have so
> many restrictions, why not just use Linux containers with WINE inside?
>

Because Wine is not Windows either, and there could be subtle differences
in how things run / interact with the system.
Plus some of our software would like to test certain system level
infrastructure (like say KDE Connect).

Plus, we have to have native Windows to compile things anyway as we need to
use MSVC (otherwise you have no Qt Web Engine support, as that cannot be
built with MingW)
(and you cannot really mix MingW / MSVC binaries due to incompatible
compiler ABIs for C++ code)

Cheers,
Ben

Re: Post-MegaRelease projects

[Ben Cooksley]

On Fri, Feb 23, 2024 at 11:12 PM Sune Vuorela  wrote:

> On 2024-02-22, Nate Graham  wrote:
> > I've started pondering post-megarelease projects. We've spent so long on
> > porting and bugfixing that I think it might be useful to shift gears to
> > feature work, and I'd like to brainstorm potential large-scale projects
> > and gauge the level of interest in putting resources into them soon.
>
> A bit more from the devops end that I'd love to see people tackle:
>
>  - Ensure frameworks and app unit tests interacting with windows can run
>on Windows.
>More details: The following fails on our windows CI
>https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp
>I find it weird that we are spending resources on putting things in
>the windows store and making apps available on windows, but we can't
>actually have passing tests in our CI.
>

This unfortunately will not be easy to solve.

One of the key things that we've learned out of doing CI, as has been
showcased by FreeBSD in particular, is that the builders need to be
ephemeral - that is only around for the build in question that is being run.
We're currently accomplishing this by using containers - via Podman (for
Linux/Android/FreeBSD) and Docker (for Windows).

Containers also offer us the advantage of allowing people to easily
reproduce the CI environment on their local system without too much trouble.

For Windows however, Microsoft has limited the container stack to not allow
anything GUI related to work. The underlying libraries may be there, but
the equivalent display server components are not operational.

To complicate things further, on Windows certain permissions are restricted
to the interactive console and are not possible to do as either a scheduled
task or as a system service.
Usage of existing Windows automation frameworks such as Powershell Remoting
or SSH will therefore not work if we want things to perfectly replicate a
end user environment - because those will run the command(s) as part of a
non-interactive session (even if the user we connect as is the same one
logged in on the desktop console).

Resolving this will therefore not only require running full sized Windows
VMs (on an ephemeral basis to avoid the recently resolved issues that used
to plague FreeBSD), but would also need the VM to automatically login and
spawn an agent as part of the interactive desktop session that we would
connect to in order to run the CI tests.

The spawning of a VM would require refactoring the setup of our poor CI
workers (again - after they were only just recently completely rebuilt to
allow the transition to Podman to fix flatpak-builder) to make use of
something like:
-
https://forum.gitlab.com/t/custom-executor-into-windows-vm-using-linux-kvm-libvirt/72713/5
- https://docs.gitlab.com/runner/executors/custom_examples/libvirt.html

We would still have to write the agent that receives our commands
(something like
https://gist.github.com/cschwede/3e2c025408ab4af531651098331cce45 maybe)

We would still have to solve the issue of how to share disk images among
our nodes so they were built (ideally would be able to use Gitlab's
Container Registry for this, which is something Tart can do - Tart being a
virtualisation management utility for ARM based Macs), as well as
automating the installation of the various OSes we need to run this way.
See
https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/automate-windows-setup?view=windows-11
for some notes on that for Windows.

The big downside to all of that of course is that the worker nodes would
take longer to startup, and it would make sharing build artifacts much more
difficult and/or less efficient.


>
>  - Find a way to run unit tests on android CI.
>

Likewise, this is very non-trivial - from my understanding our tooling
currently for building Android software is centered around it all being
cross compiled rather than being built on the native architecture it will
be run on.
Naturally tests cannot be run (unless you emulate, which I guess we could
consider...) if the CPU architectures are not compatible.

Even if you emulate though, I imagine we would need to provide a full
Android system setup (including all of it's relevant bits of system
infrastructure, such as it's display server DisplayFlinger) in order for
tests to truly be of use.
The path of least resistance is probably by making use of Google's existing
Android emulator - although i've no idea how you would tie that into CI.

We would need to have our build chains ready to build on a native system
before we could think about this I think. Building Android x86/x64 wouldn't
cover things off properly due as it won't reflect the actual CPUs being
used on end-user devices (and ARM processors can expose issues that don't
happen on x86/x64 based systems)


>
>  - Make autotests guarding on all our CI's.
>
>  - Clazy and clang-tidy and cppcheck on all our repositories in CI
>
>  /Sune
>

Hopefully 

Re: KDE Gear projects with failing CI (master) (20 February 2024)

[Ben Cooksley]

On Wed, Feb 21, 2024 at 12:01 PM 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.
>
> VERY BAD NEWS:
>  * Cantor made it to its 4th week with FreeBSD tests failing
>   * I have disabled them
> *
> https://invent.kde.org/education/cantor/-/commit/0f94f381bda4d8f7f52a432d0a846c2ca6bee1e8
>
> Good news: 8 repositories got fixed
>
> Bad news: 2 repo still failing and 5 new this week
>
> ark - 3rd week
>  * https://invent.kde.org/utilities/ark/-/pipelines/611869
>   * tests fail on FreeBSD
>

Wonder if the tests properly handle umask being set?


>
>
> merkuro - 3rd week
>  * https://invent.kde.org/pim/merkuro/-/pipelines/611879
>   * tests fail on FreeBSD
>
>
> korganizer - 1st week
>  * https://invent.kde.org/pim/korganizer/-/pipelines/611877
>   * Fails to compile, complains about Akonadi::CollectionCalendar
> constructor
>

Going to assume this is just poor propagation of API changes within PIM.
I have triggered the seed jobs for PIM for all platforms, across both
master and stable to cleanup the breakage.


>
>
> klickety - 1st week
>  * https://invent.kde.org/games/klickety/-/pipelines/611870
>   * appstreamtest fails on FreeBSD
>

Fixed now by the FreeBSD image rebuild.


>
>
> okular - 1st week
>  * https://invent.kde.org/graphics/okular/-/pipelines/611868
>   * Android fails to compile
>* It works for me locally so help needed
>

Possibly caused by different versions of the Android SDK/NDK - do we need
to rebuild everything due to BIC in Android?
The Android images have been rebuilt in the past week which may have caused
this.


>
> keysmith - 1st week
>  * https://invent.kde.org/utilities/keysmith/-/pipelines/611882
>   * craft android builds fail
>

Looks like it depends on Qt5Compat but misses the dependency that was
previously dragged in transitively.
Will need a fix to the Craft blueprint for Keysmith.


>
>
> kbruch - 1st week
>  * https://invent.kde.org/education/kbruch/-/pipelines/611867
>   * craft window build fails, but i don't see any error?
>
> Cheers,
>   Albert
>

Cheers,
Ben

Re: KDE Gear projects with failing CI (release/24.02) (20 February 2024)

[Ben Cooksley]

On Wed, Feb 21, 2024 at 11:06 AM Heiko Becker  wrote:

> On Tuesday, 20 February 2024 22:30:56 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: 11 failing repositories from previous report got fixed
> >
> > Bad news: 3 repositories are still failing and 6 new repositories
> started
> > failing
>
> [...]
>
> > kmag - 2nd week
> >  * https://invent.kde.org/accessibility/kmag/-/pipelines/611893
> >   * flatpak fails in icon-not-found
>
> Ah, forgot to cherry-pick to release/24.02, but did that now.
>
> > klickety - 1st week
> >  * https://invent.kde.org/games/klickety/-/pipelines/611894
> >   * appstream test fails in FreeBSD
>
> This needs
>
> https://github.com/ximion/appstream/commit/d3085b7d1492766f5d7bb5de210c2b11c2e1ead9
> added to FreeBSD's appstream package  (or a new appstream release).
>

Already done by Tobias, was just stuck waiting for me to rebuild our
FreeBSD images, which i've now done.
Appstream continues to be an enormous thorn in my side...

Cheers,
Ben

Re: Retirement of Binary Factory

[Ben Cooksley]

On Mon, Feb 19, 2024 at 1:22 PM Harald Sitter  wrote:

> On Sun, Feb 18, 2024 at 10:23 AM Ben Cooksley  wrote:
> >
> > On Sun, Feb 18, 2024 at 2:58 PM Loren Burkholder <
> computersemiexp...@outlook.com> wrote:
> >>
> >> On Saturday, February 17, 2024 8:35:48 PM EST Ben Cooksley wrote:
> >> > On Sun, Feb 4, 2024 at 10:26 AM Ben Cooksley 
> wrote:
> >> >
> >> > The Binary Factory, alongside it's two build servers, and the Flatpak
> >> > repository it provided at https://distribute.kde.org/ has now been
> >> > decommissioned.
> >>
> >> Hi all,
> >>
> >> Just last evening, I was downloading Filelight on a Windows machine.
> Due to the machine being rather ancient and slow, I ended up going for the
> direct binary download instead of the Microsoft Store download. The
> apps.kde.org page had me download from a Binary Factory link. As of right
> now, that link is still on https://apps.kde.org/filelight/, but it
> obviously doesn't work. I haven't checked the apps.kde.org source, but it
> seems that perhaps those URLs are automatically generated for each app, so
> it should be trivial to change or remove them.
> >
> >
> > It would appear that Filelight has not yet enabled themselves for any
> form of continuous delivery builds aside from Flatpak.
> > See
> https://invent.kde.org/utilities/filelight/-/blob/master/.gitlab-ci.yml?ref_type=heads
> >
> > If Filelight contributors are still interested in supporting other
> platforms those builds will need to be added.
>
> I'm curious, why didn't you enable stuff for the things that were
> previously building on binary factory?
>

Because in the past what people have done is turn on builds for projects on
the Binary Factory that the underlying projects actually didn't care about
and had little interest in.
That was part of the reason why the Binary Factory was a bit of a
maintainability nightmare - as constant fixes were required for some
projects as they broke builds.

Hence why projects were asked to step up and enable builds themselves.

Cheers,
Ben


>
> On Sun, Feb 18, 2024 at 10:23 AM Ben Cooksley  wrote:
> >
> > On Sun, Feb 18, 2024 at 2:58 PM Loren Burkholder <
> computersemiexp...@outlook.com> wrote:
> >>
> >> On Saturday, February 17, 2024 8:35:48 PM EST Ben Cooksley wrote:
> >> > On Sun, Feb 4, 2024 at 10:26 AM Ben Cooksley 
> wrote:
> >> >
> >> > The Binary Factory, alongside it's two build servers, and the Flatpak
> >> > repository it provided at https://distribute.kde.org/ has now been
> >> > decommissioned.
> >>
> >> Hi all,
> >>
> >> Just last evening, I was downloading Filelight on a Windows machine.
> Due to the machine being rather ancient and slow, I ended up going for the
> direct binary download instead of the Microsoft Store download. The
> apps.kde.org page had me download from a Binary Factory link. As of right
> now, that link is still on https://apps.kde.org/filelight/, but it
> obviously doesn't work. I haven't checked the apps.kde.org source, but it
> seems that perhaps those URLs are automatically generated for each app, so
> it should be trivial to change or remove them.
> >
> >
> > It would appear that Filelight has not yet enabled themselves for any
> form of continuous delivery builds aside from Flatpak.
> > See
> https://invent.kde.org/utilities/filelight/-/blob/master/.gitlab-ci.yml?ref_type=heads
> >
> > If Filelight contributors are still interested in supporting other
> platforms those builds will need to be added.
> >
> >>
> >>
> >> Are there other places that need this URL replaced as well?
> https://lxr.kde.org/search?%21v=kf6-qt6&_filestring=&_string=binary-factory.kde.org
> shows that there are a number of READMEs that still link to Binary Factory,
> and Krita has some CI stuff that still references binary-factory.kde.org,
> but I have a sneaking suspicion that there are binary-factory.kde.org
> links in KDE webpages and other repositories that aren't indexed by
> lxr.kde.org.
> >
> >
> > I have a checkout of most website repositories on my local system and
> did a quick grep which showed a variety of hits. Most of them were on
> README files that were intended to show build status of the website itself.
> > Those links would have been broken for some time as websites were
> converted over a while ago.
> >
> > Affected sites content wise includes:
> > - develop.kde.org
> > - digikam.org
> > - haruna.kde.org
> > - kaidan.im
> > - kate-editor.org
> > - kdeconnect.kde.org
> > - kde.ru
> > - kdevelop.org
> > - kirogi.org
> > - kmymoney.org
> > - konversation.kde.org
> > - krita.org
> > - okular.kde.org
> > - plasma-mobile.org
> > - rkward.kde.org
> > - umbrello.kde.org
> >
> >
> >>
> >>
> >> - Loren
> >
> >
> > Cheers,
> > Ben
>

Re: Retirement of Binary Factory

[Ben Cooksley]

On Sun, Feb 18, 2024 at 2:58 PM Loren Burkholder <
computersemiexp...@outlook.com> wrote:

> On Saturday, February 17, 2024 8:35:48 PM EST Ben Cooksley wrote:
> > On Sun, Feb 4, 2024 at 10:26 AM Ben Cooksley  wrote:
> >
> > The Binary Factory, alongside it's two build servers, and the Flatpak
> > repository it provided at https://distribute.kde.org/ has now been
> > decommissioned.
>
> Hi all,
>
> Just last evening, I was downloading Filelight on a Windows machine. Due
> to the machine being rather ancient and slow, I ended up going for the
> direct binary download instead of the Microsoft Store download. The
> apps.kde.org page had me download from a Binary Factory link. As of right
> now, that link is still on https://apps.kde.org/filelight/, but it
> obviously doesn't work. I haven't checked the apps.kde.org source, but it
> seems that perhaps those URLs are automatically generated for each app, so
> it should be trivial to change or remove them.
>

It would appear that Filelight has not yet enabled themselves for any form
of continuous delivery builds aside from Flatpak.
See
https://invent.kde.org/utilities/filelight/-/blob/master/.gitlab-ci.yml?ref_type=heads

If Filelight contributors are still interested in supporting other
platforms those builds will need to be added.


>
> Are there other places that need this URL replaced as well?
> https://lxr.kde.org/search?%21v=kf6-qt6&_filestring=&_string=binary-factory.kde.org
> shows that there are a number of READMEs that still link to Binary Factory,
> and Krita has some CI stuff that still references binary-factory.kde.org,
> but I have a sneaking suspicion that there are binary-factory.kde.org
> links in KDE webpages and other repositories that aren't indexed by
> lxr.kde.org.
>

I have a checkout of most website repositories on my local system and did a
quick grep which showed a variety of hits. Most of them were on README
files that were intended to show build status of the website itself.
Those links would have been broken for some time as websites were converted
over a while ago.

Affected sites content wise includes:
- develop.kde.org
- digikam.org
- haruna.kde.org
- kaidan.im
- kate-editor.org
- kdeconnect.kde.org
- kde.ru
- kdevelop.org
- kirogi.org
- kmymoney.org
- konversation.kde.org
- krita.org
- okular.kde.org
- plasma-mobile.org
- rkward.kde.org
- umbrello.kde.org



>
> - Loren


Cheers,
Ben

Re: Retirement of Binary Factory

[Ben Cooksley]

On Sun, Feb 4, 2024 at 10:26 AM Ben Cooksley  wrote:

> Hi all,
>
> For some time now we have been steadily working on getting our ability to
> build everything that was previously built on the Binary Factory being
> built on Gitlab.
>
> I'm now very happy to advise that it is now possible to perform all of
> those builds on Gitlab (and depending on how far you configure it, go even
> further than what was being done before). This transition to Gitlab builds
> should also ensure we use resources more efficiently, as builds will only
> take place when code actually changes (rather than every day - which is
> what the Binary Factory did).
>
> As such, with Gitlab now able to replace it, I am scheduling the Binary
> Factory for decommissioning in 2 weeks time.
> Projects relying on signed binary builds of their project should therefore
> look into migrating their builds immediately and without delay.
>

The Binary Factory, alongside it's two build servers, and the Flatpak
repository it provided at https://distribute.kde.org/ has now been
decommissioned.


>
> The legacy Flatpak repository at http://distribute.kde.org/ will also be
> retired as part of this. Anyone still using this should migrate to the
> per-application Flatpak repositories at https://cdn.kde.org/flatpak/
> noting that if you are adding the repository directly you may need to add
> the KF6 runtime first.
>
> Redirects will not be provided from the older Binary Factory URLs as there
> is no successor URL for many of the Binary Factory endpoints.
>
> Details on how to setup your project with binary builds can be found at
> https://invent.kde.org/sysadmin/ci-utilities/-/tree/master/gitlab-templates
>
> For enabling signed builds of your project builds please see
> https://invent.kde.org/sysadmin/ci-utilities/-/blob/master/signing/README.md.
> Please note that signing is only permitted on mainline repository branches
> marked as protected within Gitlab (which is only done for release branches
> such as master and release/24.04). If your project is missing from the
> configuration please submit a merge request to sysadmin/ci-utilities.
>
> Signing services include publishing Android builds to our F-Droid
> repositories (https://cdn.kde.org/android/), Flatpak repositories (
> https://cdn.kde.org/flatpak/), as well as the staging publishers that
> upload draft submissions to Google Play and the Microsoft Store (for those
> applications using those) - in addition to the actual signing of binaries
> (supported for Linux Flatpak, Android, Windows and Mac).
>
> With regards to macOS, pending fixes in the upstream tooling we use
> (rcodesign) the signing service will also be able to provide notarised
> builds.
> See https://invent.kde.org/sysadmin/ci-notary-service/-/merge_requests/38
> for more information on that.
>
> At this time signing of Appimages to allow use with AppimageUpdate is not
> supported, however to my knowledge this is not used anywhere in KDE outside
> of Krita.
>
> Similarly, work on changing our GItlab configuration to protect tags will
> be needed before we can perform signed builds on tags (see
> https://docs.gitlab.com/ee/user/project/protected_tags.html).
> Based on the documentation this should not be too difficult however so
> i'll add that to the list to look into sooner rather than later (as making
> this change also has implications for the CI system in general)
>
> Thanks,
> Ben
>
>
>
Cheers,
Ben

Re: Retirement of Binary Factory

[Ben Cooksley]

On Sun, Feb 4, 2024 at 10:26 AM Ben Cooksley  wrote:

> Hi all,
>
> For some time now we have been steadily working on getting our ability to
> build everything that was previously built on the Binary Factory being
> built on Gitlab.
>
> I'm now very happy to advise that it is now possible to perform all of
> those builds on Gitlab (and depending on how far you configure it, go even
> further than what was being done before). This transition to Gitlab builds
> should also ensure we use resources more efficiently, as builds will only
> take place when code actually changes (rather than every day - which is
> what the Binary Factory did).
>
> As such, with Gitlab now able to replace it, I am scheduling the Binary
> Factory for decommissioning in 2 weeks time.
> Projects relying on signed binary builds of their project should therefore
> look into migrating their builds immediately and without delay.
>

The Binary Factory, alongside it's two build servers, and the Flatpak
repository it provided at https://distribute.kde.org/ has now been
decommissioned.


>
> The legacy Flatpak repository at http://distribute.kde.org/ will also be
> retired as part of this. Anyone still using this should migrate to the
> per-application Flatpak repositories at https://cdn.kde.org/flatpak/
> noting that if you are adding the repository directly you may need to add
> the KF6 runtime first.
>
> Redirects will not be provided from the older Binary Factory URLs as there
> is no successor URL for many of the Binary Factory endpoints.
>
> Details on how to setup your project with binary builds can be found at
> https://invent.kde.org/sysadmin/ci-utilities/-/tree/master/gitlab-templates
>
> For enabling signed builds of your project builds please see
> https://invent.kde.org/sysadmin/ci-utilities/-/blob/master/signing/README.md.
> Please note that signing is only permitted on mainline repository branches
> marked as protected within Gitlab (which is only done for release branches
> such as master and release/24.04). If your project is missing from the
> configuration please submit a merge request to sysadmin/ci-utilities.
>
> Signing services include publishing Android builds to our F-Droid
> repositories (https://cdn.kde.org/android/), Flatpak repositories (
> https://cdn.kde.org/flatpak/), as well as the staging publishers that
> upload draft submissions to Google Play and the Microsoft Store (for those
> applications using those) - in addition to the actual signing of binaries
> (supported for Linux Flatpak, Android, Windows and Mac).
>
> With regards to macOS, pending fixes in the upstream tooling we use
> (rcodesign) the signing service will also be able to provide notarised
> builds.
> See https://invent.kde.org/sysadmin/ci-notary-service/-/merge_requests/38
> for more information on that.
>
> At this time signing of Appimages to allow use with AppimageUpdate is not
> supported, however to my knowledge this is not used anywhere in KDE outside
> of Krita.
>
> Similarly, work on changing our GItlab configuration to protect tags will
> be needed before we can perform signed builds on tags (see
> https://docs.gitlab.com/ee/user/project/protected_tags.html).
> Based on the documentation this should not be too difficult however so
> i'll add that to the list to look into sooner rather than later (as making
> this change also has implications for the CI system in general)
>
> Thanks,
> Ben
>
>
>
Cheers,
Ben

Re: KDE Frameworks with failing CI (kf5) (11 February 2024)

[Ben Cooksley]

On Sun, Feb 11, 2024 at 1:13 PM 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
>
>
> baloo - 3rd week
>  * https://invent.kde.org/frameworks/baloo/-/pipelines/604706
>   * Tests fail on FreeBSD
>
>
> kfilemetadata - 3rd week
>  * https://invent.kde.org/frameworks/kfilemetadata/-/pipelines/604707
>   * Tests fail on FreeBSD
>* Should we backport the fix made in KF6? Christoph?
>

Yes, it should be backported, otherwise the metadata features are broken on
FreeBSD 14+ for users.


>
>
> Cheers,
>   Albert
>

Cheers,
Ben

Re: KDE Gear projects with failing CI (release/24.02) (6 February 2024)

[Ben Cooksley]

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)

[Ben Cooksley]

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

Re: Flatpak jobs on KDE CI vs. continuous integration on main/master/devel branches

[Ben Cooksley]

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

Re: Flatpak jobs on KDE CI vs. continuous integration on main/master/devel branches

[Ben Cooksley]

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

Re: Flatpak jobs on KDE CI vs. continuous integration on main/master/devel branches

[Ben Cooksley]

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",
>

Please see https://invent.kde.org/packaging/flatpak-kde-runtime/-/tree/kf6
for what is in the KF6 preview.


>
> What can be done here to reestablish the old immediate continuous
> integration
> workflow? Where new APIs (also from KF) are instantly available?
>

With Flatpak new APIs were never instantly available - there has always
been a delay as the Flatpak Runtime uses the most recent released version
of our software.


>
> 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.
>

Those applications that have a hard dependency on features being added to
Frameworks are not good candidates for making use of our Continuous
Delivery systems i'm afraid.
Both Flatpak and Craft based (Linux Appimages, Android APKs, Windows and
macOS) CD jobs are best optimised for those applications that rely on the
stable Frameworks releases.

There are ways (in .craft.ini) to make newer Frameworks available, but that
requires that the system recompiles that Framework each time you trigger a
build and is therefore not recommended.

Allowing those systems to use the "latest" artifacts of Frameworks would be
a non-trivial exercise.


> So, how to solve those problems? Did I miss something?
> Could flatpak builds on master branches be made on-demand rather?


> Cheers
> Friedrich
>

Cheers,
Ben

Re: Flatpak jobs on KDE CI vs. continuous integration on main/master/devel branches

[Ben Cooksley]

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",
>

Please see https://invent.kde.org/packaging/flatpak-kde-runtime/-/tree/kf6
for what is in the KF6 preview.


>
> What can be done here to reestablish the old immediate continuous
> integration
> workflow? Where new APIs (also from KF) are instantly available?
>

With Flatpak new APIs were never instantly available - there has always
been a delay as the Flatpak Runtime uses the most recent released version
of our software.


>
> 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.
>

Those applications that have a hard dependency on features being added to
Frameworks are not good candidates for making use of our Continuous
Delivery systems i'm afraid.
Both Flatpak and Craft based (Linux Appimages, Android APKs, Windows and
macOS) CD jobs are best optimised for those applications that rely on the
stable Frameworks releases.

There are ways (in .craft.ini) to make newer Frameworks available, but that
requires that the system recompiles that Framework each time you trigger a
build and is therefore not recommended.

Allowing those systems to use the "latest" artifacts of Frameworks would be
a non-trivial exercise.


> So, how to solve those problems? Did I miss something?
> Could flatpak builds on master branches be made on-demand rather?


> Cheers
> Friedrich
>

Cheers,
Ben

Re: KDE Frameworks with failing CI (master) (4 February 2024)

[Ben Cooksley]

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
>
>
> 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

Retirement of Binary Factory

[Ben Cooksley]

Hi all,

For some time now we have been steadily working on getting our ability to
build everything that was previously built on the Binary Factory being
built on Gitlab.

I'm now very happy to advise that it is now possible to perform all of
those builds on Gitlab (and depending on how far you configure it, go even
further than what was being done before). This transition to Gitlab builds
should also ensure we use resources more efficiently, as builds will only
take place when code actually changes (rather than every day - which is
what the Binary Factory did).

As such, with Gitlab now able to replace it, I am scheduling the Binary
Factory for decommissioning in 2 weeks time.
Projects relying on signed binary builds of their project should therefore
look into migrating their builds immediately and without delay.

The legacy Flatpak repository at http://distribute.kde.org/ will also be
retired as part of this. Anyone still using this should migrate to the
per-application Flatpak repositories at https://cdn.kde.org/flatpak/ noting
that if you are adding the repository directly you may need to add the KF6
runtime first.

Redirects will not be provided from the older Binary Factory URLs as there
is no successor URL for many of the Binary Factory endpoints.

Details on how to setup your project with binary builds can be found at
https://invent.kde.org/sysadmin/ci-utilities/-/tree/master/gitlab-templates

For enabling signed builds of your project builds please see
https://invent.kde.org/sysadmin/ci-utilities/-/blob/master/signing/README.md.
Please note that signing is only permitted on mainline repository branches
marked as protected within Gitlab (which is only done for release branches
such as master and release/24.04). If your project is missing from the
configuration please submit a merge request to sysadmin/ci-utilities.

Signing services include publishing Android builds to our F-Droid
repositories (https://cdn.kde.org/android/), Flatpak repositories (
https://cdn.kde.org/flatpak/), as well as the staging publishers that
upload draft submissions to Google Play and the Microsoft Store (for those
applications using those) - in addition to the actual signing of binaries
(supported for Linux Flatpak, Android, Windows and Mac).

With regards to macOS, pending fixes in the upstream tooling we use
(rcodesign) the signing service will also be able to provide notarised
builds.
See https://invent.kde.org/sysadmin/ci-notary-service/-/merge_requests/38
for more information on that.

At this time signing of Appimages to allow use with AppimageUpdate is not
supported, however to my knowledge this is not used anywhere in KDE outside
of Krita.

Similarly, work on changing our GItlab configuration to protect tags will
be needed before we can perform signed builds on tags (see
https://docs.gitlab.com/ee/user/project/protected_tags.html).
Based on the documentation this should not be too difficult however so i'll
add that to the list to look into sooner rather than later (as making this
change also has implications for the CI system in general)

Thanks,
Ben

Retirement of Binary Factory

[Ben Cooksley]

Hi all,

For some time now we have been steadily working on getting our ability to
build everything that was previously built on the Binary Factory being
built on Gitlab.

I'm now very happy to advise that it is now possible to perform all of
those builds on Gitlab (and depending on how far you configure it, go even
further than what was being done before). This transition to Gitlab builds
should also ensure we use resources more efficiently, as builds will only
take place when code actually changes (rather than every day - which is
what the Binary Factory did).

As such, with Gitlab now able to replace it, I am scheduling the Binary
Factory for decommissioning in 2 weeks time.
Projects relying on signed binary builds of their project should therefore
look into migrating their builds immediately and without delay.

The legacy Flatpak repository at http://distribute.kde.org/ will also be
retired as part of this. Anyone still using this should migrate to the
per-application Flatpak repositories at https://cdn.kde.org/flatpak/ noting
that if you are adding the repository directly you may need to add the KF6
runtime first.

Redirects will not be provided from the older Binary Factory URLs as there
is no successor URL for many of the Binary Factory endpoints.

Details on how to setup your project with binary builds can be found at
https://invent.kde.org/sysadmin/ci-utilities/-/tree/master/gitlab-templates

For enabling signed builds of your project builds please see
https://invent.kde.org/sysadmin/ci-utilities/-/blob/master/signing/README.md.
Please note that signing is only permitted on mainline repository branches
marked as protected within Gitlab (which is only done for release branches
such as master and release/24.04). If your project is missing from the
configuration please submit a merge request to sysadmin/ci-utilities.

Signing services include publishing Android builds to our F-Droid
repositories (https://cdn.kde.org/android/), Flatpak repositories (
https://cdn.kde.org/flatpak/), as well as the staging publishers that
upload draft submissions to Google Play and the Microsoft Store (for those
applications using those) - in addition to the actual signing of binaries
(supported for Linux Flatpak, Android, Windows and Mac).

With regards to macOS, pending fixes in the upstream tooling we use
(rcodesign) the signing service will also be able to provide notarised
builds.
See https://invent.kde.org/sysadmin/ci-notary-service/-/merge_requests/38
for more information on that.

At this time signing of Appimages to allow use with AppimageUpdate is not
supported, however to my knowledge this is not used anywhere in KDE outside
of Krita.

Similarly, work on changing our GItlab configuration to protect tags will
be needed before we can perform signed builds on tags (see
https://docs.gitlab.com/ee/user/project/protected_tags.html).
Based on the documentation this should not be too difficult however so i'll
add that to the list to look into sooner rather than later (as making this
change also has implications for the CI system in general)

Thanks,
Ben

Re: KDE Frameworks with failing CI (master) (29 January 2024)

[Ben Cooksley]

On Sun, Feb 4, 2024 at 5:17 AM  wrote:

> On 2024-02-03 08:57, Ben Cooksley wrote:
> > On Wed, Jan 31, 2024 at 9:25 PM Ben Cooksley 
> > wrote:
> >
> >> On Wed, Jan 31, 2024 at 9:06 AM Volker Krause 
> >> wrote:
> >>
> >>> On Dienstag, 30. Januar 2024 19:08:50 CET Ben Cooksley wrote:
> >>>> On Wed, Jan 31, 2024 at 5:10 AM Volker Krause
> >>>  wrote:
> >>>>> On Dienstag, 30. Januar 2024 09:57:32 CET Ben Cooksley wrote:
> >>>>>> On Tue, Jan 30, 2024 at 8:47 PM Sune Vuorela
> >>>  wrote:
> >>>>>> > On 2024-01-29, Albert Astals Cid  wrote:
> >>>>>> > > Bad news: 6 repositories have started failing
> >>>>>> > >
> >>>>>> > > baloo:
> >>>>>> > > kconfig:
> >>>>>> > > kcontacts
> >>>>>> > > kfilemetadata:
> >>>>>> > > ki18n:
> >>>>>> > >
> >>>>>> > > threadweaver:
> >>>>>> > >   * FreeBSD tests are failing
> >>>>>> >
> >>>>>> > I haven't studied these, and don't know if they are
> >>> frequent or
> >>>>>> > occasional failures. I have seen, after the fbsd builder
> >>> changes, that
> >>>>>> > test execution times have gone up 20-50%. If it is big
> >>> tests that is
> >>>>>> > already close to the limit, then that might be the reason.
> >>>>>> >
> >>>>>> > Or for others with occasional timeout tests on freebsd.
> >>>>>>
> >>>>>> Having a quick look at this, it seems that quite a few of
> >>> those failures
> >>>>>> are i18n related.
> >>>>>> Given we are seeing locale warnings I have a suspicion that
> >>> is the cause
> >>>>>
> >>>>> of
> >>>>>
> >>>>>> many of those failures.
> >>>>>
> >>>>> For ki18n and kcontacts another possible cause could be the
> >>> iso-codes
> >>>>> translation catalogs missing. Are those by any chance packaged
> >>> separately
> >>>>> as
> >>>>> on some Linux distributions?
> >>>>
> >>>> I've checked and we do have iso-codes installed within the
> >>> FreeBSD
> >>>> containers.
> >>>> The files are located at /usr/local/share/iso-codes/ though -
> >>> will our
> >>>> logic find them there?
> >>>
> >>> Yes, the iso-codes data file are found, the tests would show very
> >>> explicit
> >>> error messages and fail in many more places otherwise. We however
> >>> also need
> >>> the corresponding translation catalogs, not just the data files.
> >>> On Linux those
> >>> are in /usr/share/locale/*/LC_MESSAGE/iso_3166*.mo (but often
> >>> separately
> >>> packaged and thus missing).
> >>
> >> Those files are present, although in FreeBSD fashion they are at
> >> /usr/local/share/ instead of /usr/share/:
> >>
> >> /usr/local/share/locale/tr/LC_MESSAGES/iso_3166-1.mo
> >> /usr/local/share/locale/tr/LC_MESSAGES/iso_3166-3.mo
> >> /usr/local/share/locale/tr/LC_MESSAGES/iso_3166-2.mo
> >> /usr/local/share/locale/tr/LC_MESSAGES/iso_3166.mo
> >> /usr/local/share/locale/tr/LC_MESSAGES/iso_3166_2.mo
> >>
> >> Confusingly, and in a way that probably doesn't help software:
> >>
> >> [user@399f8cd87e55 ~]$ ls -lah /usr/share/locale/tr_TR.UTF-8/
> >> total 52
> >> drwxr-xr-x2 root wheel8B Jan 30 10:28 .
> >> drwxr-xr-x  197 root wheel  197B Jan 30 10:28 ..
> >> -r--r--r--1 root wheel   79K Jan 25 15:04 LC_COLLATE
> >> lrwxr-xr-x1 root wheel   19B Jan 25 15:04 LC_CTYPE ->
> >> ../C.UTF-8/LC_CTYPE
> >> -r--r--r--1 root wheel  167B Jan 25 15:04 LC_MESSAGES
> >> -r--r--r--1 root wheel   34B Jan 25 15:04 LC_MONETARY
> >> -r--r--r--1 root wheel6B Jan 25 15:04 LC_NUMERIC
> >> -r--r--r--1 root wheel  374B Jan 25 15:04 LC_TIME
> >
> > The issue was figured out thanks to the work of frinring - who figured
> > out that LC_ALL and LANGUAGE had been set in our FreeBSD containers.
> > That has now been rectified, and the tests in several more Frameworks
> > now pass.
> >
> > (Leaving just Baloo and KFileMetaData as broken I believe)
>
> Hi,
>
> could it be that extended attributes don't work?
>
> I think these tests rely on them.
>

Good suspect, however I test some testing and it seems to work fine:

[user@8a025cda8c7b ~]$ touch file
[user@8a025cda8c7b ~]$ lsextattr user file
file
[user@8a025cda8c7b ~]$ setextattr user test value1 file
[user@8a025cda8c7b ~]$ lsextattr user file
filetest
[user@8a025cda8c7b ~]$ getextattr user test file
filevalue1

The file system in use here is ZFS if it helps anyone.


> Greetings
> Christoph
>

Cheers,
Ben

Re: KDE Frameworks with failing CI (master) (29 January 2024)

[Ben Cooksley]

On Wed, Jan 31, 2024 at 9:25 PM Ben Cooksley  wrote:

> On Wed, Jan 31, 2024 at 9:06 AM Volker Krause  wrote:
>
>> On Dienstag, 30. Januar 2024 19:08:50 CET Ben Cooksley wrote:
>> > On Wed, Jan 31, 2024 at 5:10 AM Volker Krause  wrote:
>> > > On Dienstag, 30. Januar 2024 09:57:32 CET Ben Cooksley wrote:
>> > > > On Tue, Jan 30, 2024 at 8:47 PM Sune Vuorela 
>> wrote:
>> > > > > On 2024-01-29, Albert Astals Cid  wrote:
>> > > > > > Bad news: 6 repositories have started failing
>> > > > > >
>> > > > > > baloo:
>> > > > > > kconfig:
>> > > > > > kcontacts
>> > > > > > kfilemetadata:
>> > > > > > ki18n:
>> > > > > >
>> > > > > > threadweaver:
>> > > > > >   * FreeBSD tests are failing
>> > > > >
>> > > > > I haven't studied these, and don't know if they are frequent or
>> > > > > occasional failures. I have seen, after the fbsd builder changes,
>> that
>> > > > > test execution times have gone up 20-50%. If it is big tests that
>> is
>> > > > > already close to the limit, then that might be the reason.
>> > > > >
>> > > > > Or for others with occasional timeout tests on freebsd.
>> > > >
>> > > > Having a quick look at this, it seems that quite a few of those
>> failures
>> > > > are i18n related.
>> > > > Given we are seeing locale warnings I have a suspicion that is the
>> cause
>> > >
>> > > of
>> > >
>> > > > many of those failures.
>> > >
>> > > For ki18n and kcontacts another possible cause could be the iso-codes
>> > > translation catalogs missing. Are those by any chance packaged
>> separately
>> > > as
>> > > on some Linux distributions?
>> >
>> > I've checked and we do have iso-codes installed within the FreeBSD
>> > containers.
>> > The files are located at /usr/local/share/iso-codes/ though - will our
>> > logic find them there?
>>
>> Yes, the iso-codes data file are found, the tests would show very
>> explicit
>> error messages and fail in many more places otherwise. We however also
>> need
>> the corresponding translation catalogs, not just the data files. On Linux
>> those
>> are in /usr/share/locale/*/LC_MESSAGE/iso_3166*.mo (but often separately
>> packaged and thus missing).
>>
>
> Those files are present, although in FreeBSD fashion they are at
> /usr/local/share/ instead of /usr/share/:
>
> /usr/local/share/locale/tr/LC_MESSAGES/iso_3166-1.mo
> /usr/local/share/locale/tr/LC_MESSAGES/iso_3166-3.mo
> /usr/local/share/locale/tr/LC_MESSAGES/iso_3166-2.mo
> /usr/local/share/locale/tr/LC_MESSAGES/iso_3166.mo
> /usr/local/share/locale/tr/LC_MESSAGES/iso_3166_2.mo
>
> Confusingly, and in a way that probably doesn't help software:
>
> [user@399f8cd87e55 ~]$ ls -lah /usr/share/locale/tr_TR.UTF-8/
> total 52
> drwxr-xr-x2 root wheel8B Jan 30 10:28 .
> drwxr-xr-x  197 root wheel  197B Jan 30 10:28 ..
> -r--r--r--1 root wheel   79K Jan 25 15:04 LC_COLLATE
> lrwxr-xr-x1 root wheel   19B Jan 25 15:04 LC_CTYPE ->
> ../C.UTF-8/LC_CTYPE
> -r--r--r--1 root wheel  167B Jan 25 15:04 LC_MESSAGES
> -r--r--r--1 root wheel   34B Jan 25 15:04 LC_MONETARY
> -r--r--r--1 root wheel6B Jan 25 15:04 LC_NUMERIC
> -r--r--r--1 root wheel  374B Jan 25 15:04 LC_TIME
>

The issue was figured out thanks to the work of frinring - who figured out
that LC_ALL and LANGUAGE had been set in our FreeBSD containers.
That has now been rectified, and the tests in several more Frameworks now
pass.

(Leaving just Baloo and KFileMetaData as broken I believe)


>
>
>>
>> Regards,
>> Volker
>
>
> Cheers,
> Ben
>

Cheers,
Ben

Re: KDE Gear projects with failing CI (release/23.08) (23 January 2024)

[Ben Cooksley]

On Thu, Feb 1, 2024 at 6:40 AM Volker Krause  wrote:

> On Mittwoch, 31. Januar 2024 00:12:20 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: 10 repositories that were failing are fixed :)
> >
> > Bad news: 6 repositories are still failing and 2 new repositories are
> > failing
> >
> >
> > akonadi-search - 2nd week
> >  * https://invent.kde.org/pim/akonadi-search/-/pipelines/594413
> >   * various tests are failing in FreeBSD
>
> Same as with 24.02, half-fixed by backporting https://invent.kde.org/pim/
> akonadi/-/merge_requests/171
> , the remaining
> issues are due to the missing
> MySQL support in QtSQL.
>

I've investigated this and there are a combination of two issues here,
however when it comes to the MySQL driver: it appears that there is a
packaging conflict preventing it from being installed.
@tcberner - apparently it wants mysql80-client explicitly and wants to
throw out mariadb106-client and mariadb106-server?

Even if we fix this, it looks like MySQL has the same dependency on System
V IPC that Postgres has, which is not supported within FreeBSD Jails...


>
> Regards,
> Volker
>

Cheers,
Ben

Re: Automation & Systematization sprint in Berlin in late April

[Ben Cooksley]

On Thu, Feb 1, 2024 at 12:26 PM Nate Graham  wrote:

> Hello folks!
>
> I'd like to gauge interest in an in-person sprint supporting the
> Automation & Systematization goal. Right now we are targeting Berlin on
> April 19th - April 24th. KDE e.V. has budget available to help with
> travel and lodging costs.
>
> This will be a triple-threat sprint, with the Accessibility and
> Sustainability sprints co-located. People interested in multiple topics
> will be able to jump between them if they want.
>
> Topics for the Automation & Systematization sprint might include:
> - Writing tests
> - Fixing failing tests
> - Making tests mandatory to pass
> - Documenting how to write good tests
> - Updating outdated documentation
> - Transition documentation to code (e.g. making kdesrc-build or the new
> kde-builder tool do more itself, so we don't have to write so much about
> it in our documentation)
> - Make a push for enabling clang-format for more repos
> - Make a push to put release notes in AppStream metadata
> - Improve our AppStream CI job to require or recommend more things

- Make a CI job to enforce as much of the onboarding/new repo checklist
> as possible, and make enabling it be a part of the process
>
> These are just ideas; the folks who attend will be the ones who guide
> the agenda.
>

If this ends up happening, please do keep me in the loop on what you're
thinking of building so I can provide the necessary guidance to make it
easy to deploy things that are built :)


>
> Let me know if you're interested so I can get a sense of the level of
> attendance!
>
>
> Nate
>

Cheers,
Ben

Re: KDE Gear projects with failing CI (release/23.08) (23 January 2024)

[Ben Cooksley]

On Wed, Jan 31, 2024 at 12:12 PM 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: 10 repositories that were failing are fixed :)
>
> Bad news: 6 repositories are still failing and 2 new repositories are
> failing
>
> gwenview - 2nd week
>  * https://invent.kde.org/graphics/gwenview/-/pipelines/594392
>   * FreeBSD is missing kImageAnnotator
>

This is installed, appears that Gwenview needs adapting to handle
kImageAnnotator co-installability:

[root@d76c3b549f88 /]# ls -lah
/usr/local/lib/cmake/kImageAnnotator-Qt5/kImageAnnotator-*
-rw-r--r--  1 root wheel  1.8K Jan 24 21:41
/usr/local/lib/cmake/kImageAnnotator-Qt5/kImageAnnotator-Qt5Config-version.cmake
-rw-r--r--  1 root wheel  1.1K Jan 24 21:41
/usr/local/lib/cmake/kImageAnnotator-Qt5/kImageAnnotator-Qt5Config.cmake
-rw-r--r--  1 root wheel  1.0K Jan 24 21:41
/usr/local/lib/cmake/kImageAnnotator-Qt5/kImageAnnotator-targets-release.cmake
-rw-r--r--  1 root wheel  4.1K Jan 24 21:41
/usr/local/lib/cmake/kImageAnnotator-Qt5/kImageAnnotator-targets.cmake


>
>
> spectacle - 2nd week
>  * https://invent.kde.org/graphics/spectacle/-/pipelines/594400
>   * linux CI has undefined symbols on linking
>

KPipeWire had been neglected and no longer had a functional CI
configuration, and the old binaries were broken by an ffmpeg upgrade in the
SUSE images.
Fixed in
https://invent.kde.org/plasma/kpipewire/-/commit/b68a04e4f53854f53f71d20184f7ec9b8a8e2afd
which allowed KPipeWire to be rebuilt.

With that fixed, Spectacle is happy again.


>
>
> kio-extras - 2nd week
>  * https://invent.kde.org/network/kio-extras/-/pipelines/594409
>   * thumbnailtest is failing in FreeBSD
>

Possibly due to different JPEG libraries in FreeBSD vs. OpenSUSE?


>
>
> akonadi-search - 2nd week
>  * https://invent.kde.org/pim/akonadi-search/-/pipelines/594413
>   * various tests are failing in FreeBSD
>

For anything that depends on starting up an instance of MySQL or Postgres
(to my knowledge, only Akonadi does this) that will be broken on FreeBSD
for now due to limitations in how FreeBSD Jails work.
It looks like some level of support may have landed in the FreeBSD kernel
to make things happen here (see
https://forums.freebsd.org/threads/security-jail-sysvmsg-sysvsem-sysvshm-do-we-really-need-all-of-them.75339/)
however that is not yet available in our containers.


>
>
> ark - 2nd week
>  * https://invent.kde.org/utilities/ark/-/pipelines/594402
>   * kerfuffle-extracttest fails on FreeBSD
>

Not sure why this happening - looks like a umask issue potentially, or an
incompatibility between Qt and ZFS on FreeBSD when it comes to file system
permissions?


>
> kipi-plugins - 2nd week
>  * https://invent.kde.org/graphics/kipi-plugins/-/pipelines/594430
>   * libmediawiki isn't found
>
>
> cantor - NEW
>  * https://invent.kde.org/education/cantor/-/pipelines/594390
>   * testmaxima fails on FreeBSD
>
>
> klickety - NEW
>  * https://invent.kde.org/games/klickety/-/pipelines/594405
>   * appstreamtest fails on FreeBSD
>

Apparently appstream is being silly and does not like redirects.
This is likely a change in the new version (>1.0) of Appstream which is why
we don't see it on Linux as that still has a manually compiled in older
(and patched) version of Appstream in our CI image.


>
> Cheers,
>   Albert
>

Cheers,
Ben

Re: KDE Frameworks with failing CI (master) (29 January 2024)

[Ben Cooksley]

On Wed, Jan 31, 2024 at 9:06 AM Volker Krause  wrote:

> On Dienstag, 30. Januar 2024 19:08:50 CET Ben Cooksley wrote:
> > On Wed, Jan 31, 2024 at 5:10 AM Volker Krause  wrote:
> > > On Dienstag, 30. Januar 2024 09:57:32 CET Ben Cooksley wrote:
> > > > On Tue, Jan 30, 2024 at 8:47 PM Sune Vuorela 
> wrote:
> > > > > On 2024-01-29, Albert Astals Cid  wrote:
> > > > > > Bad news: 6 repositories have started failing
> > > > > >
> > > > > > baloo:
> > > > > > kconfig:
> > > > > > kcontacts
> > > > > > kfilemetadata:
> > > > > > ki18n:
> > > > > >
> > > > > > threadweaver:
> > > > > >   * FreeBSD tests are failing
> > > > >
> > > > > I haven't studied these, and don't know if they are frequent or
> > > > > occasional failures. I have seen, after the fbsd builder changes,
> that
> > > > > test execution times have gone up 20-50%. If it is big tests that
> is
> > > > > already close to the limit, then that might be the reason.
> > > > >
> > > > > Or for others with occasional timeout tests on freebsd.
> > > >
> > > > Having a quick look at this, it seems that quite a few of those
> failures
> > > > are i18n related.
> > > > Given we are seeing locale warnings I have a suspicion that is the
> cause
> > >
> > > of
> > >
> > > > many of those failures.
> > >
> > > For ki18n and kcontacts another possible cause could be the iso-codes
> > > translation catalogs missing. Are those by any chance packaged
> separately
> > > as
> > > on some Linux distributions?
> >
> > I've checked and we do have iso-codes installed within the FreeBSD
> > containers.
> > The files are located at /usr/local/share/iso-codes/ though - will our
> > logic find them there?
>
> Yes, the iso-codes data file are found, the tests would show very explicit
> error messages and fail in many more places otherwise. We however also
> need
> the corresponding translation catalogs, not just the data files. On Linux
> those
> are in /usr/share/locale/*/LC_MESSAGE/iso_3166*.mo (but often separately
> packaged and thus missing).
>

Those files are present, although in FreeBSD fashion they are at
/usr/local/share/ instead of /usr/share/:

/usr/local/share/locale/tr/LC_MESSAGES/iso_3166-1.mo
/usr/local/share/locale/tr/LC_MESSAGES/iso_3166-3.mo
/usr/local/share/locale/tr/LC_MESSAGES/iso_3166-2.mo
/usr/local/share/locale/tr/LC_MESSAGES/iso_3166.mo
/usr/local/share/locale/tr/LC_MESSAGES/iso_3166_2.mo

Confusingly, and in a way that probably doesn't help software:

[user@399f8cd87e55 ~]$ ls -lah /usr/share/locale/tr_TR.UTF-8/
total 52
drwxr-xr-x2 root wheel8B Jan 30 10:28 .
drwxr-xr-x  197 root wheel  197B Jan 30 10:28 ..
-r--r--r--1 root wheel   79K Jan 25 15:04 LC_COLLATE
lrwxr-xr-x1 root wheel   19B Jan 25 15:04 LC_CTYPE ->
../C.UTF-8/LC_CTYPE
-r--r--r--1 root wheel  167B Jan 25 15:04 LC_MESSAGES
-r--r--r--1 root wheel   34B Jan 25 15:04 LC_MONETARY
-r--r--r--1 root wheel6B Jan 25 15:04 LC_NUMERIC
-r--r--r--1 root wheel  374B Jan 25 15:04 LC_TIME


>
> Regards,
> Volker


Cheers,
Ben

Re: Defining a developer name for our applications metadata

[Ben Cooksley]

On Wed, Jan 31, 2024 at 7:04 AM Timothée Ravier  wrote:

> Hi folks,
>
> Flathub is now requiring that applications define a "developer_name" tag
> in their metadata (see [1], [2]).
>
> What do folks think would be a good value for our application there?
>
> Based on the suggestion in the documentation [3], I started making PRs [4]
> [5] [6] [7] for our KDE Apps with "The KDE Community" as the
> "developer_name" tag.
>

Wait, so Flathub has begun requiring an older tag that the Appstream
developers have deprecated?

So we need to add tags to our metadata that are already deprecated and
which are going to result in future failures of our own unit tests when
upstream pulls the plug on developer_name as a tag and makes it a warning
deprecation rather than an information deprecation?


> I'm open to suggestions.
>
> Thanks,
>

Cheers,
Ben


>
> [1]
> https://docs.flathub.org/docs/for-app-authors/appdata-guidelines/#name-summary-and-developer-name
> [2]
> https://docs.flathub.org/docs/for-app-authors/linter/#appstream-missing-developer-name
> [3]
> https://freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-developer
> [4] https://invent.kde.org/graphics/gwenview/-/merge_requests/249
> [5] https://invent.kde.org/system/dolphin/-/merge_requests/708
> [6] https://invent.kde.org/multimedia/kdenlive/-/merge_requests/465
> [7] https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/531
>
> --
>
> Timothée Ravier
>
> CoreOS co-Team Lead
>
> Red Hat 
>
> trav...@redhat.com
> 
>

Re: KDE Frameworks with failing CI (master) (29 January 2024)

[Ben Cooksley]

On Wed, Jan 31, 2024 at 5:10 AM Volker Krause  wrote:

> On Dienstag, 30. Januar 2024 09:57:32 CET Ben Cooksley wrote:
> > On Tue, Jan 30, 2024 at 8:47 PM Sune Vuorela  wrote:
> > > On 2024-01-29, Albert Astals Cid  wrote:
> > > > Bad news: 6 repositories have started failing
> > > >
> > > > baloo:
> > > > kconfig:
> > > > kcontacts
> > > > kfilemetadata:
> > > > ki18n:
> > > >
> > > > threadweaver:
> > > >   * FreeBSD tests are failing
> > >
> > > I haven't studied these, and don't know if they are frequent or
> > > occasional failures. I have seen, after the fbsd builder changes, that
> > > test execution times have gone up 20-50%. If it is big tests that is
> > > already close to the limit, then that might be the reason.
> > >
> > > Or for others with occasional timeout tests on freebsd.
> >
> > Having a quick look at this, it seems that quite a few of those failures
> > are i18n related.
> > Given we are seeing locale warnings I have a suspicion that is the cause
> of
> > many of those failures.
>
> For ki18n and kcontacts another possible cause could be the iso-codes
> translation catalogs missing. Are those by any chance packaged separately
> as
> on some Linux distributions?
>

I've checked and we do have iso-codes installed within the FreeBSD
containers.
The files are located at /usr/local/share/iso-codes/ though - will our
logic find them there?

Following the installation of locales, i'm happy to report that kconfig and
threadweaver are fixed, so that is one part of the puzzle at least.


>
> Regards,
> Volker
>

Cheers,
Ben

Re: KDE Frameworks with failing CI (kf5) (29 January 2024)

[Ben Cooksley]

On Tue, Jan 30, 2024 at 11:59 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.
>
> Bad news: 11 repositories started failing
>
>
> baloo:
>  * https://invent.kde.org/frameworks/baloo/-/pipelines/593597
>   * Tests fail on FreeBSD
>

Looks like the same failure we see on master, where the file watcher
appears to be asked to watch an invalid path.
Do we know if the correct path is being passed in here?


>
>
> kfilemetadata:
>  * https://invent.kde.org/frameworks/kfilemetadata/-/pipelines/593602
>   * Tests fail on FreeBSD


>
> kwidgetaddons:
>  * https://invent.kde.org/frameworks/kwidgetsaddons/-/pipelines/593612
>   * Windows static fails to compile
>
>
> kemoticons:
>  * https://invent.kde.org/frameworks/kemoticons/-/pipelines/593601
>   * Fails because of ecm_feature_summary
>
>
> kdelibs4support:
>  * https://invent.kde.org/frameworks/kdelibs4support/-/pipelines/593599
>   * Fails because of ecm_feature_summary
>
>
> khtml:
>  * https://invent.kde.org/frameworks/khtml/-/pipelines/593603
>   * Fails because of ecm_feature_summary
>
>
> kjs:
>  * https://invent.kde.org/frameworks/kjs/-/pipelines/593606
>   * Fails because of ecm_feature_summary
>
>
> kjsembed:
>  * https://invent.kde.org/frameworks/kjsembed/-/pipelines/593607
>   * Fails because of ecm_feature_summary
>
>
> kmediaplater:
>  * https://invent.kde.org/frameworks/kmediaplayer/-/pipelines/593608
>   * Fails because of ecm_feature_summary
>
>
> kross:
>  * https://invent.kde.org/frameworks/kross/-/pipelines/593610
>   * Fails because of ecm_feature_summary
>
>
> kxmlrpcclient:
>  * https://invent.kde.org/frameworks/kxmlrpcclient/-/pipelines/593613
>   * Fails because of ecm_feature_summary
>
>
> Cheers,
>   Albert
>

Cheers,
Ben

Re: Ready-to-use Docker images for KF6-based development ?

[Ben Cooksley]

On Tue, Jan 30, 2024 at 10:17 AM Alexander Neundorf 
wrote:

> Hi,
>

Hi Alex,


>
> I'm still running a Qt5/KF5-based setup on my machine.
> Is there a ready-to-use docker image/Dockerfile which I could use to work
> on a
> KF6-based application, maybe something from KDE neon ?
>

I'd suggest taking a look at invent.kde.org/sysadmin/ci-images which has a
number of images that contain dependencies for just about all KDE software.
These images are used by the CI system and are published in the container
registry so you don't have to build them yourself - you can just "docker
pull" them and you should be good to go.

The Linux images there are based on OpenSUSE and are based on the
assumption you will be building all KDE software (including Frameworks and
Phonon) yourself but you could easily install those if you wanted.


>
> Sorry for the maybe stupid question
> Alex
>

Cheers,
Ben

Re: KDE Frameworks with failing CI (master) (29 January 2024)

[Ben Cooksley]

On Tue, Jan 30, 2024 at 8:47 PM Sune Vuorela  wrote:

> On 2024-01-29, Albert Astals Cid  wrote:
> > Bad news: 6 repositories have started failing
> >
> > baloo:
> > kconfig:
> > kcontacts
> > kfilemetadata:
> > ki18n:
> > threadweaver:
> >   * FreeBSD tests are failing
>
> I haven't studied these, and don't know if they are frequent or
> occasional failures. I have seen, after the fbsd builder changes, that
> test execution times have gone up 20-50%. If it is big tests that is
> already close to the limit, then that might be the reason.
>
> Or for others with occasional timeout tests on freebsd.
>

Having a quick look at this, it seems that quite a few of those failures
are i18n related.
Given we are seeing locale warnings I have a suspicion that is the cause of
many of those failures.

Tobias, any ideas here?


>
> /Sune
>
>
Cheers,
Ben

Re: What can we expect from our developers

[Ben Cooksley]

On Mon, Jan 29, 2024 at 10:38 PM Sune Vuorela  wrote:

> On 2024-01-29, Jonathan Riddell  wrote:
> > This sort of comment  makes me really sad. The All About the Apps goal,
> > which in principle is still ongoing, was an attempt to get KDE developers
> > to realise it was important not just to write apps but to actually make
> > them available to users, I find it astonishing how we still don't have a
> > culture where making our apps available to users is part of our
> > responsibility.  There's teams in KDE to help with all these formats.
> > Sorry to complain here as the issue is larger than just this one app but
> > it's so sad that nobody within KDE wants to help get users using our
> > software directly.
>
> I think this is taking it too far. I think the goal is more about not
> getting in the way of people who wants to do this.
>
> We need to draw a line somewhere about what we expect from *all* of our
> developers.
>
> I don't think that we can expect all of our developers to be great at
>  * c++
>  * qtquick
>  * cmake
>  * windows weirdness
>  * linux weirdness
>  * freebsd weirdness
>  * osx weirdness
>  * android weirdness
>  * packaging flatpaks, appimages, snaps, debs, rpm, .. for linux
>  * making osx installers
>  * making apk's
>  * making windows installers
> Beside the domain of the application.
>
> Yet it is kind of what we are doing with having gating CI setups for
> many of these, and adding more.


> I'm quite a seasoned developer and I know I can't care for all of that.
> I also don't have the time to care for all of these.


> We also don't have extra manpower in the teams that knows about these to
> help everywhere.
>
> We might have a goal about this, but this is just far too many thing to
> be good at everything.
>
> I don't think we should shame individual developers for also realizing
> this.
>
> But where should we draw the line ?
>

For the various platform weirdnesses, it really comes down to whether you
as the team behind an application (even if that team is one person) are
looking to support said platform in some way or another.
If there is interest in supporting the application - then you'll need to
resolve those weirdnesses for that platform - and can then usually build on
that to get it packaged. If you are not, then it shouldn't be there.

This is part of the reason why the KDE on Windows project transitioned to
providing single installers for a specific application (using what is now
called Craft) rather than the package manager type approach taken in the
KDE 4 era.
You can't just compile everything and hope the user experience will be
good, as tuning does need to be done to deliver an optimised installer and
to ensure that everything works properly (such as the application being
able to find the various assets it needs such as icons, QML files, etc).

The only exception to the above would be libraries or other shared
components where other people depend on you (where even if you as a
specific library aren't too concerned about say Android support, there may
still be applications that use you that do care so you should continue to
have CI for those platforms).

>From my perspective it is unreasonable to require people to package for
every platform/format under the sun.

That comes with a caveat though - that if you are looking to get visibility
for your software on other platforms (say Android and Windows) then you
would need to look into the requisite packaging work for that platform (as
it is unreasonable to expect the team that maintains Craft, etc to do that
work). The same would apply for nightly Linux builds, where you'd be
expected to look into the Appimage or Flatpak packaging. That isn't to say
they wouldn't provide pointers or advice, but a degree of investment from
your side in making it work seems to be a reasonable expectation.

The good news here though is that Craft packaging is pretty good at being
shared between platforms - so you can often get things like Windows and
Linux Appimages for the price of one piece of work.

In terms of the original goal that Jonathan was mentioning - my
interpretation of it was to make this as pain free as possible to achieve.
Something that we have mostly done through Gitlab CD systems, which have
the ability to turn out Flatpak bundles, Linux Appimages, Android APKs and
Windows installers and portable archives.


>
> /Sune
>
>
Cheers,
Ben

Re: KDE Gear projects with failing CI (master) (23 January 2024)

[Ben Cooksley]

On Thu, Jan 25, 2024 at 6:04 AM Volker Krause  wrote:

> On Dienstag, 23. Januar 2024 21:35:56 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: 5 repositories got fixed
> >
> > Bad news: 2 repo still failing (1 with a different failure) and *10* new
> > this week
>
> KMime is fixed in all branches now, the test regression in akonadi-search
> in
> master is also fixed, but the general FreeBSD fallout breaking MySQL and
> PostgreSQL Akonadi tests remains.
>

I'll be performing a rebuild of the FreeBSD images shortly following a
patch Tobias has provided to add two additional packages to ensure QtSQL
has the necessary modules available.
That will fix the MySQL tests.

Postgres not working is a known issue with FreeBSD Jails i'm afraid, as by
default FreeBSD disables Sys V IPC support within Jails (as it can't be
namespaced on FreeBSD).
While for conventional FreeBSD Jails this can be re-enabled, i'm not sure
how well that interfaces with the ocijail component used by Podman to
launch our containers.


>
> Regards,
> Volker


Cheers,
Ben

Re: KDE Gear projects with failing CI (master) (23 January 2024)

[Ben Cooksley]

On Wed, Jan 24, 2024 at 10:25 AM Tobias C. Berner 
wrote:

> Moin moin
>
> I'll take a look at krdc -- the main issue there is that cmake does
> not pick up the cmake files from the location they get installed to by
> the freerdp2 package.
> I hot-fixed that on the old builders, but not in the package. An
> update to appstream should also be feasible.


> I'll try to get to both tomorrow.
>

Thanks Tobias.
Guess changing over to the container image approach of running FreeBSD is
exposing a few things :)

Do we know where FreeRDP2 is installing it's CMake files and whether it is
just wrong (which should be fixed in the packaging, or even better upstream
with FreeRDP2 itself) or whether that is something where the CI tools just
need to hold CMake's hand a bit more?

Cheers,
Ben


>
>
> mfg Tobias
>
> On Tue, 23 Jan 2024 at 22:11, Ben Cooksley  wrote:
> >
> > On Wed, Jan 24, 2024 at 9:36 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: 5 repositories got fixed
> >>
> >> Bad news: 2 repo still failing (1 with a different failure) and *10*
> new this week
> >>
> >>
> >> krecorder - 2nd week
> >>  * https://invent.kde.org/utilities/krecorder/-/pipelines/589469
> >>   * All the craft_android builds are broken
> >
> >
> > Looks like kirigami-addons is doing something the CMake in the Android
> image doesn't like.
> >
> > Interesting - perhaps the CMake (which is built from source I think)
> version in the Android image needs updating?
> >
> >>
> >>
> >>
> >> krdc - different issue
> >>  * https://invent.kde.org/network/krdc/-/pipelines/589457
> >>   * FreeBSD builder is missing dependencies
> >
> >
> > KRDC developers should submit a MR to sysadmin/ci-images for the two
> FreeBSD 14 images please.
> >
> >>
> >>
> >>
> >> akonadi-serach - NEW
> >>  * https://invent.kde.org/pim/akonadi-search/-/pipelines/589458
> >>   * multiple tests failing
> >>
> >>
> >> kmail - NEW
> >>  * https://invent.kde.org/pim/kmail/-/pipelines/589460
> >>   * appstreamtest fails on FreeBSD
> >>
> >>
> >> kasts - NEW
> >>  * https://invent.kde.org/multimedia/kasts/-/pipelines/589466
> >>   * appstreamtest fails on FreeBSD
> >>
> >>
> >> keysmith - NEW
> >>  * https://invent.kde.org/utilities/keysmith/-/pipelines/589467
> >>   * appstreamtest fails on FreeBSD
> >>
> >>
> >> neochat - NEW
> >>  * https://invent.kde.org/network/neochat/-/pipelines/589470
> >>   * appstreamtest fails on FreeBSD
> >>
> >>
> >> cantor - NEW
> >>  * https://invent.kde.org/education/cantor/-/pipelines/589452
> >>   * testmaxima fails on FreeBSD
> >
> >
> > These appstream failures are all the fault of the Appstream developers
> for deprecating something with too high a severity level.
> > While we do need to fix it the issue is not critical yet.
> >
> > Tobias - can we please update to 1.0.1 in FreeBSD (See
> https://github.com/ximion/appstream/blob/main/NEWS#L12)?
> >
> > For Linux this does not appear as we are pinned to a self-compiled
> version in the image that is patched to align with the Flatpak requirements
> which are stricter in some areas (because appstream politics *sigh*)
> >
> >>
> >>
> >>
> >> konsole - NEW
> >>  * https://invent.kde.org/utilities/konsole/-/pipelines/589450
> >>   * flatpak build complains about icon-not-found
> >>
> >>
> >> dolphin - NEW
> >>  * https://invent.kde.org/system/dolphin/-/pipelines/589451
> >>   * flatpak build complains about icon-not-found
> >
> >
> > Both likely a case of Flatpak becoming more strict, as the version lock
> we had in place due to Docker incompatibilities was lifted following the
> move to Podman.
> >
> >>
> >>
> >>
> >> gwenview - NEW
> >>  * https://invent.kde.org/graphics/gwenview/-/pipelines/589454
> >>   * cfitsio SHA doesn't match on flatpak build
> >>
> >>
> >> kipi-plugins - NEW
> >>  * https://invent.kde.org/graphics/kipi-plugins/-/pipelines/589461
> >>   * CI fails to find libmediawiki
> >
> >
> > Do we know how much this is still used, and whether KIPI can be retired?
> >
> >>
> >>
> >>
> >>
> >>
> >> Cheers,
> >>   Albert
> >
> >
> > Cheers,
> > Ben
>

Re: KDE Gear projects with failing CI (master) (23 January 2024)

[Ben Cooksley]

On Wed, Jan 24, 2024 at 9:36 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: 5 repositories got fixed
>
> Bad news: 2 repo still failing (1 with a different failure) and *10* new
> this week
>
>
> krecorder - 2nd week
>  * https://invent.kde.org/utilities/krecorder/-/pipelines/589469
>   * All the craft_android builds are broken
>

Looks like kirigami-addons is doing something the CMake in the Android
image doesn't like.

Interesting - perhaps the CMake (which is built from source I think)
version in the Android image needs updating?


>
>
> krdc - different issue
>  * https://invent.kde.org/network/krdc/-/pipelines/589457
>   * FreeBSD builder is missing dependencies
>

KRDC developers should submit a MR to sysadmin/ci-images for the two
FreeBSD 14 images please.


>
>
> akonadi-serach - NEW
>  * https://invent.kde.org/pim/akonadi-search/-/pipelines/589458
>   * multiple tests failing
>
>
> kmail - NEW
>  * https://invent.kde.org/pim/kmail/-/pipelines/589460
>   * appstreamtest fails on FreeBSD
>
>
> kasts - NEW
>  * https://invent.kde.org/multimedia/kasts/-/pipelines/589466
>   * appstreamtest fails on FreeBSD
>
>
> keysmith - NEW
>  * https://invent.kde.org/utilities/keysmith/-/pipelines/589467
>   * appstreamtest fails on FreeBSD
>
>
> neochat - NEW
>  * https://invent.kde.org/network/neochat/-/pipelines/589470
>   * appstreamtest fails on FreeBSD
>
>
> cantor - NEW
>  * https://invent.kde.org/education/cantor/-/pipelines/589452
>   * testmaxima fails on FreeBSD
>

These appstream failures are all the fault of the Appstream developers for
deprecating something with too high a severity level.
While we do need to fix it the issue is not critical yet.

Tobias - can we please update to 1.0.1 in FreeBSD (See
https://github.com/ximion/appstream/blob/main/NEWS#L12)?

For Linux this does not appear as we are pinned to a self-compiled version
in the image that is patched to align with the Flatpak requirements which
are stricter in some areas (because appstream politics *sigh*)


>
>
> konsole - NEW
>  * https://invent.kde.org/utilities/konsole/-/pipelines/589450
>   * flatpak build complains about icon-not-found
>
>
> dolphin - NEW
>  * https://invent.kde.org/system/dolphin/-/pipelines/589451
>   * flatpak build complains about icon-not-found
>

Both likely a case of Flatpak becoming more strict, as the version lock we
had in place due to Docker incompatibilities was lifted following the move
to Podman.


>
>
> gwenview - NEW
>  * https://invent.kde.org/graphics/gwenview/-/pipelines/589454
>   * cfitsio SHA doesn't match on flatpak build
>
>
> kipi-plugins - NEW
>  * https://invent.kde.org/graphics/kipi-plugins/-/pipelines/589461
>   * CI fails to find libmediawiki


Do we know how much this is still used, and whether KIPI can be retired?


>


>
> Cheers,
>   Albert
>

Cheers,
Ben

Re: Major CI changes - FreeBSD and Linux

[Ben Cooksley]

On Mon, Jan 22, 2024 at 10:08 PM Ben Cooksley  wrote:

> Hi all,
>
> Over the past few weeks significant work has been undertaken to develop
> the ability to make use of containerised builds for FreeBSD.
>
> Over the weekend i'm happy to report that this has now been rolled out and
> is now in use across all 5 CI workers that support invent.kde.org. This
> means going forward that we should no longer experience issues with running
> out of disk space on our FreeBSD CI jobs anymore, and we will have the
> ability to ensure others can easily reproduce our setup on their local
> system.
>
> The FreeBSD images for Qt 5.15 and Qt 6.6 that are in use can be found at
> https://invent.kde.org/sysadmin/ci-images along with the other images we
> publish. For those curious about how to set up their own builder,
> instructions can be found in the gitlab-templates/ folder of
> sysadmin/ci-utilities (instructions are also present there for Linux and
> Windows).
>
> Alongside this, we've also transitioned from using Docker on the Linux
> side of the CI workers to using rootless (unprivileged) Podman containers.
> This change was necessitated by changes to Bubblewrap, which is the
> underlying container technology used by flatpak-builder, that made it
> incompatible with the workarounds we previously had in place to run it
> under Docker.
>
> For most projects, this should not pose any issues however due to a last
> minute issue that was discovered during the rollout the DRM virtual gem
> devices while present won't be accessible. To my knowledge this only
> impacts KWin.
> It is possible other projects that were doing actions in their tests that
> need some form of privilege (such as invoking a debugger) may also be
> affected, however in theory there should not be much difference between the
> two container implementations.
>
> This change has also come along with a switch to Debian Bookworm (and the
> 6.1.0 kernel that comes with it) which depending on your tests could also
> have an impact.
>
> The underlying operating system in use within our Linux CI images is not
> changed and continues to be OpenSUSE for desktop Linux, and Ubuntu 22.04
> for Android mobile builds.
>
> At this time the setup for building of Linux images has yet to be adapted,
> so that capability is temporarily unavailable. It is expected to be
> restored in the coming days.
> Until that is completed, we will be unable to rebuild any of our Linux
> images.
>

This has now been corrected and should be functional again.


>
> Thanks,
> Ben
>

Cheers,
Ben

Re: Major CI changes - FreeBSD and Linux

[Ben Cooksley]

On Mon, Jan 22, 2024 at 10:08 PM Ben Cooksley  wrote:

> Hi all,
>
> Over the past few weeks significant work has been undertaken to develop
> the ability to make use of containerised builds for FreeBSD.
>
> Over the weekend i'm happy to report that this has now been rolled out and
> is now in use across all 5 CI workers that support invent.kde.org. This
> means going forward that we should no longer experience issues with running
> out of disk space on our FreeBSD CI jobs anymore, and we will have the
> ability to ensure others can easily reproduce our setup on their local
> system.
>
> The FreeBSD images for Qt 5.15 and Qt 6.6 that are in use can be found at
> https://invent.kde.org/sysadmin/ci-images along with the other images we
> publish. For those curious about how to set up their own builder,
> instructions can be found in the gitlab-templates/ folder of
> sysadmin/ci-utilities (instructions are also present there for Linux and
> Windows).
>
> Alongside this, we've also transitioned from using Docker on the Linux
> side of the CI workers to using rootless (unprivileged) Podman containers.
> This change was necessitated by changes to Bubblewrap, which is the
> underlying container technology used by flatpak-builder, that made it
> incompatible with the workarounds we previously had in place to run it
> under Docker.
>
> For most projects, this should not pose any issues however due to a last
> minute issue that was discovered during the rollout the DRM virtual gem
> devices while present won't be accessible. To my knowledge this only
> impacts KWin.
> It is possible other projects that were doing actions in their tests that
> need some form of privilege (such as invoking a debugger) may also be
> affected, however in theory there should not be much difference between the
> two container implementations.
>
> This change has also come along with a switch to Debian Bookworm (and the
> 6.1.0 kernel that comes with it) which depending on your tests could also
> have an impact.
>
> The underlying operating system in use within our Linux CI images is not
> changed and continues to be OpenSUSE for desktop Linux, and Ubuntu 22.04
> for Android mobile builds.
>
> At this time the setup for building of Linux images has yet to be adapted,
> so that capability is temporarily unavailable. It is expected to be
> restored in the coming days.
> Until that is completed, we will be unable to rebuild any of our Linux
> images.
>

This has now been corrected and should be functional again.


>
> Thanks,
> Ben
>

Cheers,
Ben

Re: Major CI changes - FreeBSD and Linux

[Ben Cooksley]

On Mon, Jan 22, 2024 at 10:08 PM Ben Cooksley  wrote:

> Hi all,
>
> Over the past few weeks significant work has been undertaken to develop
> the ability to make use of containerised builds for FreeBSD.
>
> Over the weekend i'm happy to report that this has now been rolled out and
> is now in use across all 5 CI workers that support invent.kde.org. This
> means going forward that we should no longer experience issues with running
> out of disk space on our FreeBSD CI jobs anymore, and we will have the
> ability to ensure others can easily reproduce our setup on their local
> system.
>
> The FreeBSD images for Qt 5.15 and Qt 6.6 that are in use can be found at
> https://invent.kde.org/sysadmin/ci-images along with the other images we
> publish. For those curious about how to set up their own builder,
> instructions can be found in the gitlab-templates/ folder of
> sysadmin/ci-utilities (instructions are also present there for Linux and
> Windows).
>
> Alongside this, we've also transitioned from using Docker on the Linux
> side of the CI workers to using rootless (unprivileged) Podman containers.
> This change was necessitated by changes to Bubblewrap, which is the
> underlying container technology used by flatpak-builder, that made it
> incompatible with the workarounds we previously had in place to run it
> under Docker.
>
> For most projects, this should not pose any issues however due to a last
> minute issue that was discovered during the rollout the DRM virtual gem
> devices while present won't be accessible. To my knowledge this only
> impacts KWin.
> It is possible other projects that were doing actions in their tests that
> need some form of privilege (such as invoking a debugger) may also be
> affected, however in theory there should not be much difference between the
> two container implementations.
>
> This change has also come along with a switch to Debian Bookworm (and the
> 6.1.0 kernel that comes with it) which depending on your tests could also
> have an impact.
>
> The underlying operating system in use within our Linux CI images is not
> changed and continues to be OpenSUSE for desktop Linux, and Ubuntu 22.04
> for Android mobile builds.
>
> At this time the setup for building of Linux images has yet to be adapted,
> so that capability is temporarily unavailable. It is expected to be
> restored in the coming days.
> Until that is completed, we will be unable to rebuild any of our Linux
> images.
>

This has now been corrected and should be functional again.


>
> Thanks,
> Ben
>

Cheers,
Ben

Major CI changes - FreeBSD and Linux

[Ben Cooksley]

Hi all,

Over the past few weeks significant work has been undertaken to develop the
ability to make use of containerised builds for FreeBSD.

Over the weekend i'm happy to report that this has now been rolled out and
is now in use across all 5 CI workers that support invent.kde.org. This
means going forward that we should no longer experience issues with running
out of disk space on our FreeBSD CI jobs anymore, and we will have the
ability to ensure others can easily reproduce our setup on their local
system.

The FreeBSD images for Qt 5.15 and Qt 6.6 that are in use can be found at
https://invent.kde.org/sysadmin/ci-images along with the other images we
publish. For those curious about how to set up their own builder,
instructions can be found in the gitlab-templates/ folder of
sysadmin/ci-utilities (instructions are also present there for Linux and
Windows).

Alongside this, we've also transitioned from using Docker on the Linux side
of the CI workers to using rootless (unprivileged) Podman containers. This
change was necessitated by changes to Bubblewrap, which is the underlying
container technology used by flatpak-builder, that made it incompatible
with the workarounds we previously had in place to run it under Docker.

For most projects, this should not pose any issues however due to a last
minute issue that was discovered during the rollout the DRM virtual gem
devices while present won't be accessible. To my knowledge this only
impacts KWin.
It is possible other projects that were doing actions in their tests that
need some form of privilege (such as invoking a debugger) may also be
affected, however in theory there should not be much difference between the
two container implementations.

This change has also come along with a switch to Debian Bookworm (and the
6.1.0 kernel that comes with it) which depending on your tests could also
have an impact.

The underlying operating system in use within our Linux CI images is not
changed and continues to be OpenSUSE for desktop Linux, and Ubuntu 22.04
for Android mobile builds.

At this time the setup for building of Linux images has yet to be adapted,
so that capability is temporarily unavailable. It is expected to be
restored in the coming days.
Until that is completed, we will be unable to rebuild any of our Linux
images.

Thanks,
Ben

Major CI changes - FreeBSD and Linux

[Ben Cooksley]

Hi all,

Over the past few weeks significant work has been undertaken to develop the
ability to make use of containerised builds for FreeBSD.

Over the weekend i'm happy to report that this has now been rolled out and
is now in use across all 5 CI workers that support invent.kde.org. This
means going forward that we should no longer experience issues with running
out of disk space on our FreeBSD CI jobs anymore, and we will have the
ability to ensure others can easily reproduce our setup on their local
system.

The FreeBSD images for Qt 5.15 and Qt 6.6 that are in use can be found at
https://invent.kde.org/sysadmin/ci-images along with the other images we
publish. For those curious about how to set up their own builder,
instructions can be found in the gitlab-templates/ folder of
sysadmin/ci-utilities (instructions are also present there for Linux and
Windows).

Alongside this, we've also transitioned from using Docker on the Linux side
of the CI workers to using rootless (unprivileged) Podman containers. This
change was necessitated by changes to Bubblewrap, which is the underlying
container technology used by flatpak-builder, that made it incompatible
with the workarounds we previously had in place to run it under Docker.

For most projects, this should not pose any issues however due to a last
minute issue that was discovered during the rollout the DRM virtual gem
devices while present won't be accessible. To my knowledge this only
impacts KWin.
It is possible other projects that were doing actions in their tests that
need some form of privilege (such as invoking a debugger) may also be
affected, however in theory there should not be much difference between the
two container implementations.

This change has also come along with a switch to Debian Bookworm (and the
6.1.0 kernel that comes with it) which depending on your tests could also
have an impact.

The underlying operating system in use within our Linux CI images is not
changed and continues to be OpenSUSE for desktop Linux, and Ubuntu 22.04
for Android mobile builds.

At this time the setup for building of Linux images has yet to be adapted,
so that capability is temporarily unavailable. It is expected to be
restored in the coming days.
Until that is completed, we will be unable to rebuild any of our Linux
images.

Thanks,
Ben

Major CI changes - FreeBSD and Linux

[Ben Cooksley]

Hi all,

Over the past few weeks significant work has been undertaken to develop the
ability to make use of containerised builds for FreeBSD.

Over the weekend i'm happy to report that this has now been rolled out and
is now in use across all 5 CI workers that support invent.kde.org. This
means going forward that we should no longer experience issues with running
out of disk space on our FreeBSD CI jobs anymore, and we will have the
ability to ensure others can easily reproduce our setup on their local
system.

The FreeBSD images for Qt 5.15 and Qt 6.6 that are in use can be found at
https://invent.kde.org/sysadmin/ci-images along with the other images we
publish. For those curious about how to set up their own builder,
instructions can be found in the gitlab-templates/ folder of
sysadmin/ci-utilities (instructions are also present there for Linux and
Windows).

Alongside this, we've also transitioned from using Docker on the Linux side
of the CI workers to using rootless (unprivileged) Podman containers. This
change was necessitated by changes to Bubblewrap, which is the underlying
container technology used by flatpak-builder, that made it incompatible
with the workarounds we previously had in place to run it under Docker.

For most projects, this should not pose any issues however due to a last
minute issue that was discovered during the rollout the DRM virtual gem
devices while present won't be accessible. To my knowledge this only
impacts KWin.
It is possible other projects that were doing actions in their tests that
need some form of privilege (such as invoking a debugger) may also be
affected, however in theory there should not be much difference between the
two container implementations.

This change has also come along with a switch to Debian Bookworm (and the
6.1.0 kernel that comes with it) which depending on your tests could also
have an impact.

The underlying operating system in use within our Linux CI images is not
changed and continues to be OpenSUSE for desktop Linux, and Ubuntu 22.04
for Android mobile builds.

At this time the setup for building of Linux images has yet to be adapted,
so that capability is temporarily unavailable. It is expected to be
restored in the coming days.
Until that is completed, we will be unable to rebuild any of our Linux
images.

Thanks,
Ben

Re: KDE Gear projects with failing CI (release/23.08) (2 January 2024)

[Ben Cooksley]

On Wed, Jan 3, 2024 at 10:51 AM Volker Krause  wrote:

> On Dienstag, 2. Januar 2024 22:01:25 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.
> >
> > Bad news: 2 new repositories are failing :(
> >
> >
> > == Something is up with kdiagram ==
> >
> > kdepim-addons:
> >  * https://invent.kde.org/pim/kdepim-addons/-/pipelines/572121
>
> Build is still running on FreeBSD, but this should be fixed.
>
> > == Something is up with kweathercore ==
> >
> > kweather:
> >  * https://invent.kde.org/utilities/kweather/-/pipelines/572137
>
> This one is more complicated. KWeatherCore master is Qt6-only, but there
> is no
> branch for past releases, only tags. So the CI has no Qt5 build of it
> anymore,
> which however is needed for the Qt5-based KWeather build.
>
> The best I can think of right now is adding a dummy kf5 branch on the v0.7
> tag?
>

That is what I would recommend at this point. We don't support publishing
CI artifacts from tags at the moment as that requires marking them as
protected (which may cause other issues and would need to be looked into
seperately)


>
> Regards,
> Volker
>

Cheers,
Ben

Re: Re: KDE Plasma 5.27 on OpenBSD

[Ben Cooksley]

On Wed, Dec 27, 2023 at 6:52 AM Rafael Sadowski 
wrote:

> On Tue Dec 26, 2023 at 11:33:16AM -0500, Neal Gompa wrote:
> > On Tue, Dec 26, 2023 at 9:26 AM Rafael Sadowski 
> wrote:
> > >
> > > Hi,
> > >
> > > I am pleased to announce that KDE Plasma is available on OpenBSD
> > > alongside all KDE Gear 23.08.4 applications as well as Frameworks
> > > 5.113.0.
> > >
> > > Today the 26.12.23 it was enabled and will be available in the next
> > > release (or in -current rolling release).
> > >
> > > - https://twitter.com/sizeofvoid/status/1739641916050792882
> > > - https://marc.info/?l=openbsd-ports-cvs=170359681610856=4
> > > - https://marc.info/?l=openbsd-ports-cvs=170359673610818=4
> > >
> >
> > Congratulations! Out of curiosity, do you have KDE Plasma Wayland
> > working yet? I saw recently that the basic Wayland stack was ported to
> > OpenBSD and now that the Sway stack works on OpenBSD[1] and I know
> > that it works on FreeBSD already[2].
> >
> > [1]: https://homepages.laas.fr/matthieu/talks/wayland-openbsd.pdf
> > [2]: https://euroquis.nl/kde/2021/04/30/wayland.html
> >
>
> Thanks!
>
> Unfortunately no, I'm working on it. I have recorded the situation and
> orther issues in the README:
>
> https://github.com/openbsd/ports/blob/master/meta/kde/pkg/README-plasma#L68
>
> I don't want to abuse this thread, but here is the current start process
> and as you can see, the DRM device cannot be opened.
>

While it seems strange, the issue here is the lack of a properly
functioning ConsoleKit - see
https://invent.kde.org/plasma/kwin/-/blob/master/src/core/session_consolekit.cpp
Specifically, the function openRestricted there is used by KWin to open the
GPU / Display device (in
https://invent.kde.org/plasma/kwin/-/blob/master/src/backends/drm/drm_backend.cpp)
as these devices are usually owned by root.


>
> org.kde.startup: not a reply org.freedesktop.locale1
> QDBusMessage(type=Error, service="org.freedesktop.DBus", error
> name="org.freedesktop.DBus.Error.ServiceUnknown", error message="The name
> org.freedesktop.locale1 was not provided by any .service files",
> signature="s", contents=("The name org.freedesktop.locale1 was not provided
> by any .service files") )
> dbus-daemon[37069]: [session uid=1000 pid=37069] Activating service
> name='org.kde.KSplash' requested by ':1.0' (uid=1000 pid=32485
> comm="/usr/local/bin/startplasma-wayland")
> No backend specified, automatically choosing drm
> kwin_core: Failed to take control of /org/freedesktop/ConsoleKit/Session1
> session. Maybe another compositor is running?
> kwin_wayland_drm: failed to open drm device at "/dev/dri/card0"
> kwin_wayland_drm: No suitable DRM devices have been found
> No backend specified, automatically choosing drm
> kwin_core: Failed to take control of /org/freedesktop/ConsoleKit/Session1
> session. Maybe another compositor is running?
> kwin_wayland_drm: failed to open drm device at "/dev/dri/card0"
> kwin_wayland_drm: No suitable DRM devices have been found
> No backend specified, automatically choosing drm
> kwin_core: Failed to take control of /org/freedesktop/ConsoleKit/Session1
> session. Maybe another compositor is running?
> kwin_wayland_drm: failed to open drm device at "/dev/dri/card0"
> kwin_wayland_drm: No suitable DRM devices have been found
> No backend specified, automatically choosing drm
> kwin_core: Failed to take control of /org/freedesktop/ConsoleKit/Session1
> session. Maybe another compositor is running?
> kwin_wayland_drm: failed to open drm device at "/dev/dri/card0"
> kwin_wayland_drm: No suitable DRM devices have been found
> No backend specified, automatically choosing drm
> kwin_core: Failed to take control of /org/freedesktop/ConsoleKit/Session1
> session. Maybe another compositor is running?
> kwin_wayland_drm: failed to open drm device at "/dev/dri/card0"
> kwin_wayland_drm: No suitable DRM devices have been found
> No backend specified, automatically choosing drm
> kwin_core: Failed to take control of /org/freedesktop/ConsoleKit/Session1
> session. Maybe another compositor is running?
> kwin_wayland_drm: failed to open drm device at "/dev/dri/card0"
> kwin_wayland_drm: No suitable DRM devices have been found
> No backend specified, automatically choosing drm
> kwin_core: Failed to take control of /org/freedesktop/ConsoleKit/Session1
> session. Maybe another compositor is running?
> kwin_wayland_drm: failed to open drm device at "/dev/dri/card0"
> kwin_wayland_drm: No suitable DRM devices have been found
> No backend specified, automatically choosing drm
> kwin_core: Failed to take control of /org/freedesktop/ConsoleKit/Session1
> session. Maybe another compositor is running?
> kwin_wayland_drm: failed to open drm device at "/dev/dri/card0"
> kwin_wayland_drm: No suitable DRM devices have been found
> No backend specified, automatically choosing drm
> kwin_core: Failed to take control of /org/freedesktop/ConsoleKit/Session1
> session. Maybe another compositor is running?
> kwin_wayland_drm: failed to open 

Re: Remove/ Archive Obsolete or Disabled Bugzilla Product/Components

[Ben Cooksley]

On Tue, Dec 19, 2023 at 7:31 AM  wrote:

> On 2023-12-18 19:14, Ben Cooksley wrote:
> > On Mon, Dec 18, 2023 at 7:48 PM Shubham Arora
> >  wrote:
> >
> >> Hi Ben,
> >>
> >> Nate suggested on matrix that we can move inactive components to a
> >> "Archived" project. This way they will not be visible under original
> >> project. Also is it possible to move the inactive projects further
> >> down the list.
> >
> > That is quite a bit of work, as you can't really move inactive
> > components - you have to recreate them in their new home then move all
> > the bugs over and finally delete the original inactive component.
> > Bugzilla controls the sort order once again, so you can't control the
> > sorting of projects except by renaming them to something that starts
> > with a Z.
>
> Hi,
>
> would that make anything better btw.? Disabled components should be
> invisible for bug
> reporting, I don't think they hurt anyone.
>

It would bury them from the Bugzilla searches and other places that allow
viewing bugs vs. entering them.
But you are correct that it doesn't really help much - and would actually
harm the Dr Konqi experience for people still using the old versions of
those applications as it won't tell them that it is no longer open for bug
reporting.


>
> Greetings
> Christoph
>
>
Cheers,
Ben

Re: Remove/ Archive Obsolete or Disabled Bugzilla Product/Components

[Ben Cooksley]

On Mon, Dec 18, 2023 at 7:48 PM Shubham Arora 
wrote:

> Hi Ben,
>
> Nate suggested on matrix that we can move inactive components to a
> "Archived" project. This way they will not be visible under original
> project. Also is it possible to move the inactive projects further down the
> list.


That is quite a bit of work, as you can't really move inactive components -
you have to recreate them in their new home then move all the bugs over and
finally delete the original inactive component.
Bugzilla controls the sort order once again, so you can't control the
sorting of projects except by renaming them to something that starts with a
Z.


>
> Regards,
> Shubham
>

Cheers,
Ben


>
> Sent with Proton Mail secure email.
>
> On Monday, December 18th, 2023 at 12:12 PM, Ben Cooksley <
> bcooks...@kde.org> wrote:
>
>
> > On Mon, Dec 18, 2023 at 7:21 PM Shubham Arora <
> shubhamar...@protonmail.com> wrote:
> >
> > > Hi Ben,
> > >
> > > Thanks for the response. I will move the conversation to plasma-devel
> for disabling the components.
> > >
> > > Can we archive the already disabled components? For example
> kinfocenter product has only 1 active component and around 8 inactive.
> These components are extraneous and just add to the clutter when browsing.
> >
> >
> > Unfortunately Bugzilla has no such "archival" functionality - so the
> extent that things are disabled is as good as it gets i'm afraid.
> >
> > Cheers,
> > Ben
> >
> > >
> > > Sent with Proton Mail secure email.
> > >
> > > On Monday, December 18th, 2023 at 10:51 AM, Ben Cooksley <
> bcooks...@kde.org> wrote:
> > >
> > >
> > > > On Mon, Dec 18, 2023 at 8:16 AM Shubham Arora <
> shubhamar...@protonmail.com> wrote:
> > > >
> > > > > Hi,
> > > >
> > > >
> > > > HI Shubham,
> > > >
> > > > >
> > > > > I have compiled a list of all bugzilla components and products
> that need to be archived or removed to remove some clutter from the
> bugzilla interface.
> > > > >
> > > > > All inactive components can be archived as they are no longer in
> use. Following components can probably be disabled and archived.
> > > > >
> > > > > Product ID Product Name Product Description Component ID Component
> Name Component Description
> > > > > 189 ksysguard System monitoring tool [up to Plasma 5.21] 341
> general all bugs not for other components
> > > > > 189 ksysguard System monitoring tool [up to Plasma 5.21] 1131
> ksysguard The ksysguard standalone windowed application
> > > > > 189 ksysguard System monitoring tool [up to Plasma 5.21] 1130
> ksysguardd The cli daemon process
> > > > > 189 ksysguard System monitoring tool [up to Plasma 5.21] 2438
> libksysguard ksysguard library
> > > > > 189 ksysguard System monitoring tool [up to Plasma 5.21] 1129
> Plasmoid / Applet The applet -- not the windowed ksysguard.
> > > > > 189 ksysguard System monitoring tool [up to Plasma 5.21] 1132
> Process Controller - krunner part The process controller widget
> > > > > 359 buildsystem Report issues with the buildsystem here. 981 KDE4
> (cmake) Report issues with the KDE4 buildsystem (cmake). For reporting
> issues with cmake itself use the cmake bugtracker:
> http://www.cmake.org/Bug
> > > > > 392 Oxygen A breath of fresh air. It includes a new icon set,
> sounds, a new widget style and a new window decoration. The oxygen artists
> also provide various artwork for applications (like backgrounds etc) 1795
> gtk2-engine The GTK+-2.0 implementation of the widget style
> > > > > 344 systemsettings Plasma's configuration tool 2414 kcm_formats
> The formats module in Plasma 5.25 and earlier. Do not file bugs here if you
> are using Plasma 5.26 or later!
> > > > > 643 QtCurve The QtCurve style engine for Qt and other GUI
> toolkits. 2425 gtk2 Bugs specific to the GTK+ 2 version.
> > > > > 643 QtCurve The QtCurve style engine for Qt and other GUI
> toolkits. 2427 qt4 Bugs specific to the Qt 4 version.
> > > > >
> > > > > I used this script to generate the list.
> https://invent.kde.org/-/snippets/2943
> > > > >
> > > > > Sysadmin intervention is required here as not to generate any
> emails for any existing bugs under the above components/products.
> > > >
> > > >
> > > > Components and products can be disabled/archived for new bug entry
> without affecting existing bugs.
> > > > This therefore just needs someone with sufficient access
> (edit_components rights) to do - should disabling the above be seen as
> appropriate by the component maintainers.
> > > >
> > > > Given many of these are Plasma related, probably best to discuss
> this on plasma-de...@kde.org.
> > > >
> > > > >
> > > > > Regards,
> > > >
> > > > > Shubham
> > > >
> > > >
> > > > Cheers,
> > > > Ben
> > > >
> > > > > Sent with Proton Mail secure email.
>

Re: Remove/ Archive Obsolete or Disabled Bugzilla Product/Components

[Ben Cooksley]

On Mon, Dec 18, 2023 at 7:21 PM Shubham Arora 
wrote:

> Hi Ben,
>
> Thanks for the response. I will move the conversation to plasma-devel for
> disabling the components.
>
> Can we archive the already disabled components? For example kinfocenter
> product has only 1 active component and around 8 inactive. These components
> are extraneous and just add to the clutter when browsing.
>

Unfortunately Bugzilla has no such "archival" functionality - so the extent
that things are disabled is as good as it gets i'm afraid.

Cheers,
Ben


>
> Sent with Proton Mail secure email.
>
> On Monday, December 18th, 2023 at 10:51 AM, Ben Cooksley <
> bcooks...@kde.org> wrote:
>
>
> > On Mon, Dec 18, 2023 at 8:16 AM Shubham Arora <
> shubhamar...@protonmail.com> wrote:
> >
> > > Hi,
> >
> >
> > HI Shubham,
> >
> > >
> > > I have compiled a list of all bugzilla components and products that
> need to be archived or removed to remove some clutter from the bugzilla
> interface.
> > >
> > > All inactive components can be archived as they are no longer in use.
> Following components can probably be disabled and archived.
> > >
> > > Product ID Product Name Product Description Component ID Component
> Name Component Description
> > > 189 ksysguard System monitoring tool [up to Plasma 5.21] 341 general
> all bugs not for other components
> > > 189 ksysguard System monitoring tool [up to Plasma 5.21] 1131
> ksysguard The ksysguard standalone windowed application
> > > 189 ksysguard System monitoring tool [up to Plasma 5.21] 1130
> ksysguardd The cli daemon process
> > > 189 ksysguard System monitoring tool [up to Plasma 5.21] 2438
> libksysguard ksysguard library
> > > 189 ksysguard System monitoring tool [up to Plasma 5.21] 1129 Plasmoid
> / Applet The applet -- not the windowed ksysguard.
> > > 189 ksysguard System monitoring tool [up to Plasma 5.21] 1132 Process
> Controller - krunner part The process controller widget
> > > 359 buildsystem Report issues with the buildsystem here. 981 KDE4
> (cmake) Report issues with the KDE4 buildsystem (cmake). For reporting
> issues with cmake itself use the cmake bugtracker:
> http://www.cmake.org/Bug
> > > 392 Oxygen A breath of fresh air. It includes a new icon set, sounds,
> a new widget style and a new window decoration. The oxygen artists also
> provide various artwork for applications (like backgrounds etc) 1795
> gtk2-engine The GTK+-2.0 implementation of the widget style
> > > 344 systemsettings Plasma's configuration tool 2414 kcm_formats The
> formats module in Plasma 5.25 and earlier. Do not file bugs here if you are
> using Plasma 5.26 or later!
> > > 643 QtCurve The QtCurve style engine for Qt and other GUI toolkits.
> 2425 gtk2 Bugs specific to the GTK+ 2 version.
> > > 643 QtCurve The QtCurve style engine for Qt and other GUI toolkits.
> 2427 qt4 Bugs specific to the Qt 4 version.
> > >
> > > I used this script to generate the list.
> https://invent.kde.org/-/snippets/2943
> > >
> > > Sysadmin intervention is required here as not to generate any emails
> for any existing bugs under the above components/products.
> >
> >
> > Components and products can be disabled/archived for new bug entry
> without affecting existing bugs.
> > This therefore just needs someone with sufficient access
> (edit_components rights) to do - should disabling the above be seen as
> appropriate by the component maintainers.
> >
> > Given many of these are Plasma related, probably best to discuss this on
> plasma-de...@kde.org.
> >
> > >
> > > Regards,
> >
> > > Shubham
> >
> >
> > Cheers,
> > Ben
> >
> > > Sent with Proton Mail secure email.
>

Re: Remove/ Archive Obsolete or Disabled Bugzilla Product/Components

[Ben Cooksley]

On Mon, Dec 18, 2023 at 8:16 AM Shubham Arora 
wrote:

> Hi,
>

HI Shubham,


>
> I have compiled a list of all bugzilla components and products that need
> to be archived or removed to remove some clutter from the bugzilla
> interface.
>
> All inactive components can be archived as they are no longer in use.
> Following components can probably be disabled and archived.
>
> Product ID  Product NameProduct Description Component ID
> Component Name  Component Description
> 189 ksysguard   System monitoring tool [up to Plasma 5.21]
> 341 general all bugs not for other components
> 189 ksysguard   System monitoring tool [up to Plasma 5.21]
> 1131ksysguard   The ksysguard standalone windowed application
> 189 ksysguard   System monitoring tool [up to Plasma 5.21]
> 1130ksysguardd  The cli daemon process
> 189 ksysguard   System monitoring tool [up to Plasma 5.21]
> 2438libksysguardksysguard library
> 189 ksysguard   System monitoring tool [up to Plasma 5.21]
> 1129Plasmoid / Applet   The applet -- not the windowed ksysguard.
> 189 ksysguard   System monitoring tool [up to Plasma 5.21]
> 1132Process Controller - krunner part   The process controller
> widget
> 359 buildsystem Report issues with the buildsystem here.
> 981 KDE4 (cmake)Report issues with the KDE4 buildsystem (cmake).
> For reporting issues with cmake itself use the cmake bugtracker:
> http://www.cmake.org/Bug
> 392 Oxygen  A breath of fresh air. It includes a new icon set, sounds,
> a new widget style and a new window decoration. The oxygen artists also
> provide various artwork for applications (like backgrounds etc)  1795
>   gtk2-engine The GTK+-2.0 implementation of the widget style
> 344 systemsettings  Plasma's configuration tool 2414
> kcm_formats The formats module in Plasma 5.25 and earlier.  Do not file
> bugs here if you are using Plasma 5.26 or later!
> 643 QtCurve The QtCurve style engine for Qt and other GUI toolkits.
> 2425gtk2Bugs specific to the GTK+ 2 version.
> 643 QtCurve The QtCurve style engine for Qt and other GUI toolkits.
> 2427qt4 Bugs specific to the Qt 4 version.
>
> I used this script to generate the list.
> https://invent.kde.org/-/snippets/2943
>
> Sysadmin intervention is required here as not to generate any emails for
> any existing bugs under the above components/products.
>

Components and products can be disabled/archived for new bug entry without
affecting existing bugs.
This therefore just needs someone with sufficient access (edit_components
rights) to do - should disabling the above be seen as appropriate by the
component maintainers.

Given many of these are Plasma related, probably best to discuss this on
plasma-de...@kde.org.


>
> Regards,

Shubham
>
>
Cheers,
Ben


> Sent with Proton Mail secure email.
>

qmlonline.kde.org - Updates required

[Ben Cooksley]

Hi all,

Back in May 2020, some work was done to bring a WebAssembly based build of
QML online, which resulted in https://qmlonline.kde.org/ being setup.

I'm not sure to what degree it is in use, however while looking into
porting it from the Binary Factory to Gitlab it has come to my attention it
is using a version of Debian for the image used to build the WASM binaries
that is no longer receiving updates.

Additionally, the version of Python it includes is too old to support the
CI Notary Service tools needed for publishing to our web servers.

As such we either need to port to Qt 6 and rework the foundations, or
discontinue the site accordingly.

If anyone is interested in working on this, the code can be found in
https://invent.kde.org/webapps/qmlonline/-/commits/work/enable-gitlab-ci

If nobody steps up in the next week or so then i'll set about shutting this
site down.

Cheers,
Ben

Re: Reviving lightdm-kde-greeter upstream

[Ben Cooksley]

On Thu, Nov 30, 2023 at 12:06 AM Albert Astals Cid  wrote:

> El dimarts, 28 de novembre de 2023, a les 11:25:42 (CET), Ben Cooksley va
> escriure:
> > On Tue, Nov 28, 2023 at 9:51 PM Anton Golubev 
> >
> > wrote:
> > > On 11/25/23 02:14, Albert Astals Cid wrote:
> > > > Since you don't seem to be a KDE devel just yet this would probably
> have
> > >
> > > to go
> > >
> > > > through the https://community.kde.org/Incubator program.
> > >
> > > The instructions on the link say that I need to create a new project on
> > > invent.kde.org, but it already exists[3]? what should I do? (A quick
> > > search on the list did not yield any examples)
> >
> > This is the first time that the revival of a project that has been
> archived
> > on invent.kde.org has taken place, so we're in new territory.
> > The whole point of archival of these projects though is to allow for them
> > to be restored later on.
> >
> > To proceed here, we first will need to get you a developer account - this
> > can be handled under the Incubator program, so you'll need everything
> that
> > goes along with that.
> >
> > From there, we can reinstate the unmaintained project and transfer it to
> an
> > appropriate namespace (likely Plasma given this is a workspace component,
> > and would be consistent given the SDDM KCM lives there as well).
>
> Not sure if Plasma would make sense here unless the Plasma team actually
> wants
> it, since AFAIU everything under Plasma gets released on Plasma releases,
> which may not be what is wanted here.
>

There are definitely repositories under Plasma that the Plasma team doesn't
release.

The group Plasma on invent more refers to our Workspace products, which a
LightDM greeter would fall into the realm of.
Unless someone has a better idea of where to put it?


> Anyhow, do we have someone that wants to help Incubate this?
>
> Cheers,
>   Albert
>

Cheers,
Ben


>
> > That will have to be done by a Sysadmin so please file a ticket once you
> > have a developer account. That will also allow us to facilitate catching
> up
> > the original KDE repository with the subsequent contributions that
> happened
> > in your Gitlab.com repository.
> >
> > Cheers,
> > Ben
> >
> > > > [1]: https://git.altlinux.org/gears/l/lightdm-kde-greeter.git
> > > > [2]: https://gitlab.com/golubevan/lightdm-kde-greeter
> > > > [3]: https://invent.kde.org/unmaintained/lightd
>
>
>
>
>

Re: Reviving lightdm-kde-greeter upstream

[Ben Cooksley]

On Tue, Nov 28, 2023 at 9:51 PM Anton Golubev 
wrote:

> On 11/25/23 02:14, Albert Astals Cid wrote:
> > Since you don't seem to be a KDE devel just yet this would probably have
> to go
> > through the https://community.kde.org/Incubator program.
>
> The instructions on the link say that I need to create a new project on
> invent.kde.org, but it already exists[3]? what should I do? (A quick
> search on the list did not yield any examples)
>

This is the first time that the revival of a project that has been archived
on invent.kde.org has taken place, so we're in new territory.
The whole point of archival of these projects though is to allow for them
to be restored later on.

To proceed here, we first will need to get you a developer account - this
can be handled under the Incubator program, so you'll need everything that
goes along with that.

>From there, we can reinstate the unmaintained project and transfer it to an
appropriate namespace (likely Plasma given this is a workspace component,
and would be consistent given the SDDM KCM lives there as well).
That will have to be done by a Sysadmin so please file a ticket once you
have a developer account. That will also allow us to facilitate catching up
the original KDE repository with the subsequent contributions that happened
in your Gitlab.com repository.

Cheers,
Ben


> > [1]: https://git.altlinux.org/gears/l/lightdm-kde-greeter.git
> > [2]: https://gitlab.com/golubevan/lightdm-kde-greeter
> > [3]: https://invent.kde.org/unmaintained/lightd
>

Re: Transitioning to Qt 6.6 for Windows builds - Syndication build failure

[Ben Cooksley]

On Tue, Nov 21, 2023 at 6:29 AM  wrote:

> On 2023-11-19 09:58, Ben Cooksley wrote:
> > Hi all,
> >
> > As you'll be aware, we've been working on moving CI over to Qt 6.6 for
> > a little while now, and as part of this have hit a bit of a roadblock
> > with the Framework Syndication.
> >
> > The roadblock is more likely to be due to the transition to using MSVC
> > 2022 (and all the compiler changes that come with that) however that
> > change was mandated by Qt 6.6 itself so there isn't much we can do
> > about that.
> >
> > The build failure can be seen at
> > https://invent.kde.org/sysadmin/ci-management/-/jobs/1373146 and a
> > draft fix for the issue can be found at
> > https://invent.kde.org/frameworks/syndication/-/merge_requests/26
> >
> > Any assistance with getting Syndication fixed up would be very much
> > appreciated so we can get Windows builds moved to Qt 6.6 (which will
> > leave just FreeBSD on Qt 6.5)
>
> Hi, that seems to be fixed now with the last merge, I rescheduled the
> job,
> it already passed at least the syndication step.
>

Thanks Christoph, following that enough of the other seed jobs passed so I
moved us over to Qt 6.6 for Windows CI.


>
> Greetings
> Christoph
>

Cheers,
Ben


>
> >
> > Thanks,
> > Ben
>

Re: Transitioning to Qt 6.6 for Windows builds - Syndication build failure

[Ben Cooksley]

On Tue, Nov 21, 2023 at 6:29 AM  wrote:

> On 2023-11-19 09:58, Ben Cooksley wrote:
> > Hi all,
> >
> > As you'll be aware, we've been working on moving CI over to Qt 6.6 for
> > a little while now, and as part of this have hit a bit of a roadblock
> > with the Framework Syndication.
> >
> > The roadblock is more likely to be due to the transition to using MSVC
> > 2022 (and all the compiler changes that come with that) however that
> > change was mandated by Qt 6.6 itself so there isn't much we can do
> > about that.
> >
> > The build failure can be seen at
> > https://invent.kde.org/sysadmin/ci-management/-/jobs/1373146 and a
> > draft fix for the issue can be found at
> > https://invent.kde.org/frameworks/syndication/-/merge_requests/26
> >
> > Any assistance with getting Syndication fixed up would be very much
> > appreciated so we can get Windows builds moved to Qt 6.6 (which will
> > leave just FreeBSD on Qt 6.5)
>
> Hi, that seems to be fixed now with the last merge, I rescheduled the
> job,
> it already passed at least the syndication step.
>

Thanks Christoph, following that enough of the other seed jobs passed so I
moved us over to Qt 6.6 for Windows CI.


>
> Greetings
> Christoph
>

Cheers,
Ben


>
> >
> > Thanks,
> > Ben
>

Gitlab update - CI future proofing required

[Ben Cooksley]

Hi all,

Over this weekend I completed a series of updates to invent.kde.org, moving
it to the latest supported version of Postgres (14) and Gitlab (16.6).

As part of that Gitlab update, additional security policies began to be
enforced by Gitlab which mean our existing method of including CI templates
is now beginning to be problematic.

To correct this, we need to port our .gitlab-ci.yml files over to the
include:project syntax (see
https://docs.gitlab.com/ee/ci/yaml/#includeproject)

As an example, this might look like for a Qt 6 only project with Linux,
FreeBSD and Windows builds:

include:
  - project: sysadmin/ci-utilities
file:
  - /gitlab-templates/linux-qt6.yml
  - /gitlab-templates/freebsd-qt6.yml
  - /gitlab-templates/windows-qt6.yml

While we've been able to permit the existing syntax to work for now, it is
recommended that projects please look into porting their CI configurations
now to avoid future issues.

Thanks,
Ben

Gitlab update - CI future proofing required

[Ben Cooksley]

Hi all,

Over this weekend I completed a series of updates to invent.kde.org, moving
it to the latest supported version of Postgres (14) and Gitlab (16.6).

As part of that Gitlab update, additional security policies began to be
enforced by Gitlab which mean our existing method of including CI templates
is now beginning to be problematic.

To correct this, we need to port our .gitlab-ci.yml files over to the
include:project syntax (see
https://docs.gitlab.com/ee/ci/yaml/#includeproject)

As an example, this might look like for a Qt 6 only project with Linux,
FreeBSD and Windows builds:

include:
  - project: sysadmin/ci-utilities
file:
  - /gitlab-templates/linux-qt6.yml
  - /gitlab-templates/freebsd-qt6.yml
  - /gitlab-templates/windows-qt6.yml

While we've been able to permit the existing syntax to work for now, it is
recommended that projects please look into porting their CI configurations
now to avoid future issues.

Thanks,
Ben

Gitlab update - CI future proofing required

[Ben Cooksley]

Hi all,

Over this weekend I completed a series of updates to invent.kde.org, moving
it to the latest supported version of Postgres (14) and Gitlab (16.6).

As part of that Gitlab update, additional security policies began to be
enforced by Gitlab which mean our existing method of including CI templates
is now beginning to be problematic.

To correct this, we need to port our .gitlab-ci.yml files over to the
include:project syntax (see
https://docs.gitlab.com/ee/ci/yaml/#includeproject)

As an example, this might look like for a Qt 6 only project with Linux,
FreeBSD and Windows builds:

include:
  - project: sysadmin/ci-utilities
file:
  - /gitlab-templates/linux-qt6.yml
  - /gitlab-templates/freebsd-qt6.yml
  - /gitlab-templates/windows-qt6.yml

While we've been able to permit the existing syntax to work for now, it is
recommended that projects please look into porting their CI configurations
now to avoid future issues.

Thanks,
Ben

Transitioning to Qt 6.6 for Windows builds - Syndication build failure

[Ben Cooksley]

Hi all,

As you'll be aware, we've been working on moving CI over to Qt 6.6 for a
little while now, and as part of this have hit a bit of a roadblock with
the Framework Syndication.

The roadblock is more likely to be due to the transition to using MSVC 2022
(and all the compiler changes that come with that) however that change was
mandated by Qt 6.6 itself so there isn't much we can do about that.

The build failure can be seen at
https://invent.kde.org/sysadmin/ci-management/-/jobs/1373146 and a draft
fix for the issue can be found at
https://invent.kde.org/frameworks/syndication/-/merge_requests/26

Any assistance with getting Syndication fixed up would be very much
appreciated so we can get Windows builds moved to Qt 6.6 (which will leave
just FreeBSD on Qt 6.5)

Thanks,
Ben

Transitioning to Qt 6.6 for Windows builds - Syndication build failure

[Ben Cooksley]

Hi all,

As you'll be aware, we've been working on moving CI over to Qt 6.6 for a
little while now, and as part of this have hit a bit of a roadblock with
the Framework Syndication.

The roadblock is more likely to be due to the transition to using MSVC 2022
(and all the compiler changes that come with that) however that change was
mandated by Qt 6.6 itself so there isn't much we can do about that.

The build failure can be seen at
https://invent.kde.org/sysadmin/ci-management/-/jobs/1373146 and a draft
fix for the issue can be found at
https://invent.kde.org/frameworks/syndication/-/merge_requests/26

Any assistance with getting Syndication fixed up would be very much
appreciated so we can get Windows builds moved to Qt 6.6 (which will leave
just FreeBSD on Qt 6.5)

Thanks,
Ben

Change to release flows for non-centrally released projects

[Ben Cooksley]

Hi all,

For some time now the workflow for independently released KDE software
(that is, projects outside of Frameworks, Plasma and Gear) has been to
upload it to ftp://upload.kde.org/incoming/ and then file a Sysadmin ticket
(with the file hashes and destination)

There has now been a small change to that workflow, where our tooling that
validates the hashes will now also be validating GPG signatures where they
are provided. For tarballs it is expected that you provide a GPG signature
(*.sig), but these won't be required for binary packages.

GPG signatures will be validated against a keyring built from the keys
located at https://invent.kde.org/sysadmin/release-keyring/ - so you will
now need to have your key added there in advance of filing a Sysadmin
ticket to have your release published.

Please send a merge request to that repository with your key(s) following
the format of $gitlabusern...@keyx.asc to have them added.

Many thanks,
Ben

Change to release flows for non-centrally released projects

[Ben Cooksley]

Hi all,

For some time now the workflow for independently released KDE software
(that is, projects outside of Frameworks, Plasma and Gear) has been to
upload it to ftp://upload.kde.org/incoming/ and then file a Sysadmin ticket
(with the file hashes and destination)

There has now been a small change to that workflow, where our tooling that
validates the hashes will now also be validating GPG signatures where they
are provided. For tarballs it is expected that you provide a GPG signature
(*.sig), but these won't be required for binary packages.

GPG signatures will be validated against a keyring built from the keys
located at https://invent.kde.org/sysadmin/release-keyring/ - so you will
now need to have your key added there in advance of filing a Sysadmin
ticket to have your release published.

Please send a merge request to that repository with your key(s) following
the format of $gitlabusern...@keyx.asc to have them added.

Many thanks,
Ben

Re: plasma-framework

[Ben Cooksley]

On Wed, Nov 8, 2023 at 12:22 AM Jonathan Esk-Riddell 
wrote:

> On Sun, Nov 05, 2023 at 12:59:28PM +0100, Friedrich W. H. Kossebau wrote:
> > kactivities and kactivities-stats: please consider proper de-KF-ication
> now
> >
> > Hi,
> >
> > with plasma-framework, kactivities and kactivities entering the Plasma
> product
> > bundle, I assume they also will adapt to Plasma versioning.
>
> We've done the reversioning now (thanks to those who tidied up after
> me yesterday).  We plan to rename plasma-framework to libplasma
> although I'm not sure who has the energy to do it.  I suppose we'll
> also remove the KF terms from the other ones too.
>

Are you talking about renaming the CMake/Binary side or the
repository/tarball side here?


>
> kwayland is the 4th one being moved, it has been re-versioned but not yet
> moved in invent.
>
> Jonathan
>

Cheers,
Ben

Re: CI log verbosity

[Ben Cooksley]

On Sat, Nov 4, 2023 at 2:48 AM Ingo Klöcker  wrote:

> On Freitag, 3. November 2023 13:01:26 CET Harald Sitter wrote:
> > What are your thoughts on having the CI be less verbose by default and
> > instead have an env var or some other toggle to switch into verbose
> > mode?
>
> +1
>
> Ideally, the verbose logs would be written to an artifact. Otherwise, it
> will
> be painful to debug intermittent problems. I think the Craft jobs now do
> this
> (also in response to insanely verbose output of some builds which made it
> impossible to see the actual error).
>

Unfortunately the test log output is all governed by CMake/CTest so there
isn't too much we can do ourselves - not without doing quite a bit of work
to read XML files produced by CTest anyway.


>
> > Specifically I'm talking about the qtlogging rules that are currently
> > enabling everything and the kitchen sink. To my mind we should just
> > use the default rules by default.
> > I find that 99% of the time the output is entirely useless in finding
> > what is wrong, if anything it gets in the way because I first have to
> > find where the test failure is and then instead of reading walls of qt
> > plugin info I will just proceed to reproduce the problem locally
> > anyway.
>
> Full ACK. I'm almost always only interested in finding the error which
> caused
> the CI job to fail and sometimes in seeing compiler warnings.
>
> Regards,
> Ingo
>

Cheers,
Ben

Re: CI log verbosity

[Ben Cooksley]

On Sat, Nov 4, 2023 at 1:01 AM Harald Sitter  wrote:

> What are your thoughts on having the CI be less verbose by default and
> instead have an env var or some other toggle to switch into verbose
> mode?
>
> Specifically I'm talking about the qtlogging rules that are currently
> enabling everything and the kitchen sink. To my mind we should just
> use the default rules by default.
> I find that 99% of the time the output is entirely useless in finding
> what is wrong, if anything it gets in the way because I first have to
> find where the test failure is and then instead of reading walls of qt
> plugin info I will just proceed to reproduce the problem locally
> anyway.
>

The current approach to enabling all of the debugging information was
adopted a few years back when dfaure was trying to debug some tests.
We were back on Jenkins then though, which made it quite difficult to set
things yourself, unlike what you can do now with Gitlab CI and a work
branch.

Behaviour is changed from
https://invent.kde.org/sysadmin/ci-utilities/-/commit/67e9aaac0f540005834bd61c60abf01eed01cb12

If anyone would like to propose a set of more narrow, sane logging rules
then please send an MR (would suggest that it is wrapped behind a check for
whether the logging rules variable is set already though)

Cheers,
Ben


>
> Thoughts?
>
> HS
>

Re: libkexiv2, libkdcraw (Re: Collection of packaging notes)

[Ben Cooksley]

On Fri, Nov 3, 2023 at 12:57 PM Albert Astals Cid  wrote:

> El dimecres, 1 de novembre de 2023, a les 13:25:42 (CET), Friedrich W. H.
> Kossebau va escriure:
> > Am Mittwoch, 1. November 2023, 11:55:08 CET schrieb Christophe Marin:
> > > With various alpha coming out soon, here are the notes added to my
> > > packages
> > > when I started packaging snapshots and still present.
> >
> > Thanks for the report.
> >
> > Everyone:
> > Could we perhaps establish some wiki page where such things could be
> > tracked?
>
>
> I don't particularly think wiki pages are good for tracking issues, we
> have
> issue trackers for that ;)
>
> I've proposed elsewhere to re-use the release-service issue tracker, but
> honestly I've no idea if anyone can create issues here
>   https://invent.kde.org/teams/release-service/issues/-/issues/
> or only team members, if it's only team members, it's not a great place to
> put
> things i guess unless we add lots of folks to the team (which i'm not
> against
> but they may be).
>

I have now created
https://invent.kde.org/teams/release-service/qt6-mega-release to help keep
the issues here separate from the ones you've been using to track and
manage the Gear releases.

Issues can be created by anyone, but certain actions on those issues - such
as moving them around the board, labelling them, etc. do require membership
of the group at the reporter or developer level.
See https://docs.gitlab.com/ee/user/permissions.html for more information
on this.

Cheers,
Ben


>
> Cheers,
>   Albert
>
> > > - Non frameworks modules installing libKF*.so
> > > libkexiv2 (libKF6KExiv2.so)
> >
> > Any code ideas for naming it, given there is already a number suffix,
> coming
> > from the library that is wrapped?
> >
> > Similar need also for libkomparediff2, where the 2 is referring to
> diffing 2
> > things, not a version number.
> >
> > > libkdcraw (libKF6KDcraw.so)
> >
> > I have an old patch locally somehow never finished, will brush up as MR
> > tonight hopefully. (promised in
> https://invent.kde.org/graphics/libkdcraw/-/
> > merge_requests/9#note_646025 )
> >
> > Cheers
> > Frriedrich
>
>
>
>
>

Re: Frameworks 6 alpha

[Ben Cooksley]

On Wed, Nov 1, 2023 at 8:42 AM Jonathan Riddell  wrote:

> We chatted about the alpha release due next Wednesday in the Frameworks
> meeting today.
>
> From my notes:
>
> - Frameworks would like do be part of this release
>
> - Nico F, Alex S, David E are release spods
>
> - There's not been any work on doing the tooling.  There's a desire to
> move to releaseme for tooling.  Jonathan uses this plus a load of
> supporting scripts for Plasma and will look at adapting that for Frameworks
> and come up with a proposal
>
> - Plasma would like to take over release of plasma-framework, kwayland and
> kactivities and that presumably means also kactivities-stats.  There was
> discussion on the problem of moving the gitlab entries for this while 5
> releases are still ongoing so it's probably best to just leave that for now.
>

Having the repositories being subject to two different sets of rules is
going to be quite painful - as quite a few systems assume that something in
frameworks/* is a Framework.
This is the case for CI (in the branch-rules, the seed jobs, etc), API
Documentation and a few other places.

It is much easier to make something non-Frameworks look like a Framework,
than it is to make something that is classified as Frameworks (but isn't
actually one) not be seen as one.
(ie. the rules we have are inclusionary not exclusionary)

I'd be in favour of saying they need to be moved from frameworks/ to
plasma/ in preparation for this.


>
> - oxygen-icons5 tar should be renamed oxygen-icons (again probably leave
> gitlab repo renaming until later)
>
- We didn't discuss it but kirigami2 tar should also be renamed to kirigami
>

Not sure why we need to delay renaming the repository?


>
> Does that seem right?
>
> Anything else?
>
> Jonathan
>

Thanks,
Ben

[sysadmin/ci-utilities] gitlab-templates: Move Linux CI for Qt 6 over to Qt 6.6.

[Ben Cooksley]

Git commit 55f8993e028b2597dea44077cd49eb91bb9d87e4 by Ben Cooksley.
Committed on 31/10/2023 at 10:23.
Pushed by bcooksley into branch 'master'.

Move Linux CI for Qt 6 over to Qt 6.6.

CCMAIL: kde-de...@kde.org
CCMAIL: kde-core-de...@kde.org
CCMAIL: kde-frameworks-devel@kde.org
CCMAIL: plasma-de...@kde.org

M  +5-5gitlab-templates/linux-qt6-static.yml
M  +5-5gitlab-templates/linux-qt6.yml

https://invent.kde.org/sysadmin/ci-utilities/-/commit/55f8993e028b2597dea44077cd49eb91bb9d87e4

diff --git a/gitlab-templates/linux-qt6-static.yml 
b/gitlab-templates/linux-qt6-static.yml
index 3e1f3fb..852f0b6 100644
--- a/gitlab-templates/linux-qt6-static.yml
+++ b/gitlab-templates/linux-qt6-static.yml
@@ -1,13 +1,13 @@
-suse_tumbleweed_qt65_static:
+suse_tumbleweed_qt66_static:
   stage: build
-  image: invent-registry.kde.org/sysadmin/ci-images/suse-qt65:latest
+  image: invent-registry.kde.org/sysadmin/ci-images/suse-qt66:latest
   tags:
 - Linux
   variables:
-KDECI_CC_CACHE: /mnt/caches/suse-qt6.5-static/
-KDECI_CACHE_PATH: /mnt/artifacts/suse-qt6.5-static/
+KDECI_CC_CACHE: /mnt/caches/suse-qt6.6-static/
+KDECI_CACHE_PATH: /mnt/artifacts/suse-qt6.6-static/
 KDECI_GITLAB_SERVER: https://invent.kde.org/
-KDECI_PACKAGE_PROJECT: teams/ci-artifacts/suse-qt6.5-static
+KDECI_PACKAGE_PROJECT: teams/ci-artifacts/suse-qt6.6-static
   interruptible: true
   before_script:
 - git clone https://invent.kde.org/sysadmin/ci-utilities.git --depth=1
diff --git a/gitlab-templates/linux-qt6.yml b/gitlab-templates/linux-qt6.yml
index 71e5c03..5f0ef50 100644
--- a/gitlab-templates/linux-qt6.yml
+++ b/gitlab-templates/linux-qt6.yml
@@ -1,13 +1,13 @@
-suse_tumbleweed_qt65:
+suse_tumbleweed_qt66:
   stage: build
-  image: invent-registry.kde.org/sysadmin/ci-images/suse-qt65:latest
+  image: invent-registry.kde.org/sysadmin/ci-images/suse-qt66:latest
   tags:
 - Linux
   variables:
-KDECI_CC_CACHE: /mnt/caches/suse-qt6.5/
-KDECI_CACHE_PATH: /mnt/artifacts/suse-qt6.5/
+KDECI_CC_CACHE: /mnt/caches/suse-qt6.6/
+KDECI_CACHE_PATH: /mnt/artifacts/suse-qt6.6/
 KDECI_GITLAB_SERVER: https://invent.kde.org/
-KDECI_PACKAGE_PROJECT: teams/ci-artifacts/suse-qt6.5
+KDECI_PACKAGE_PROJECT: teams/ci-artifacts/suse-qt6.6
   interruptible: true
   before_script:
 - git clone https://invent.kde.org/sysadmin/ci-utilities.git --depth=1

[sysadmin/ci-utilities] gitlab-templates: Move Linux CI for Qt 6 over to Qt 6.6.

[Ben Cooksley]

Git commit 55f8993e028b2597dea44077cd49eb91bb9d87e4 by Ben Cooksley.
Committed on 31/10/2023 at 10:23.
Pushed by bcooksley into branch 'master'.

Move Linux CI for Qt 6 over to Qt 6.6.

CCMAIL: kde-devel@kde.org
CCMAIL: kde-core-de...@kde.org
CCMAIL: kde-frameworks-de...@kde.org
CCMAIL: plasma-de...@kde.org

M  +5-5gitlab-templates/linux-qt6-static.yml
M  +5-5gitlab-templates/linux-qt6.yml

https://invent.kde.org/sysadmin/ci-utilities/-/commit/55f8993e028b2597dea44077cd49eb91bb9d87e4

diff --git a/gitlab-templates/linux-qt6-static.yml 
b/gitlab-templates/linux-qt6-static.yml
index 3e1f3fb..852f0b6 100644
--- a/gitlab-templates/linux-qt6-static.yml
+++ b/gitlab-templates/linux-qt6-static.yml
@@ -1,13 +1,13 @@
-suse_tumbleweed_qt65_static:
+suse_tumbleweed_qt66_static:
   stage: build
-  image: invent-registry.kde.org/sysadmin/ci-images/suse-qt65:latest
+  image: invent-registry.kde.org/sysadmin/ci-images/suse-qt66:latest
   tags:
 - Linux
   variables:
-KDECI_CC_CACHE: /mnt/caches/suse-qt6.5-static/
-KDECI_CACHE_PATH: /mnt/artifacts/suse-qt6.5-static/
+KDECI_CC_CACHE: /mnt/caches/suse-qt6.6-static/
+KDECI_CACHE_PATH: /mnt/artifacts/suse-qt6.6-static/
 KDECI_GITLAB_SERVER: https://invent.kde.org/
-KDECI_PACKAGE_PROJECT: teams/ci-artifacts/suse-qt6.5-static
+KDECI_PACKAGE_PROJECT: teams/ci-artifacts/suse-qt6.6-static
   interruptible: true
   before_script:
 - git clone https://invent.kde.org/sysadmin/ci-utilities.git --depth=1
diff --git a/gitlab-templates/linux-qt6.yml b/gitlab-templates/linux-qt6.yml
index 71e5c03..5f0ef50 100644
--- a/gitlab-templates/linux-qt6.yml
+++ b/gitlab-templates/linux-qt6.yml
@@ -1,13 +1,13 @@
-suse_tumbleweed_qt65:
+suse_tumbleweed_qt66:
   stage: build
-  image: invent-registry.kde.org/sysadmin/ci-images/suse-qt65:latest
+  image: invent-registry.kde.org/sysadmin/ci-images/suse-qt66:latest
   tags:
 - Linux
   variables:
-KDECI_CC_CACHE: /mnt/caches/suse-qt6.5/
-KDECI_CACHE_PATH: /mnt/artifacts/suse-qt6.5/
+KDECI_CC_CACHE: /mnt/caches/suse-qt6.6/
+KDECI_CACHE_PATH: /mnt/artifacts/suse-qt6.6/
 KDECI_GITLAB_SERVER: https://invent.kde.org/
-KDECI_PACKAGE_PROJECT: teams/ci-artifacts/suse-qt6.5
+KDECI_PACKAGE_PROJECT: teams/ci-artifacts/suse-qt6.6
   interruptible: true
   before_script:
 - git clone https://invent.kde.org/sysadmin/ci-utilities.git --depth=1

[sysadmin/ci-utilities] gitlab-templates: Move Linux CI for Qt 6 over to Qt 6.6.

[Ben Cooksley]

Git commit 55f8993e028b2597dea44077cd49eb91bb9d87e4 by Ben Cooksley.
Committed on 31/10/2023 at 10:23.
Pushed by bcooksley into branch 'master'.

Move Linux CI for Qt 6 over to Qt 6.6.

CCMAIL: kde-de...@kde.org
CCMAIL: kde-core-devel@kde.org
CCMAIL: kde-frameworks-de...@kde.org
CCMAIL: plasma-de...@kde.org

M  +5-5gitlab-templates/linux-qt6-static.yml
M  +5-5gitlab-templates/linux-qt6.yml

https://invent.kde.org/sysadmin/ci-utilities/-/commit/55f8993e028b2597dea44077cd49eb91bb9d87e4

diff --git a/gitlab-templates/linux-qt6-static.yml 
b/gitlab-templates/linux-qt6-static.yml
index 3e1f3fb..852f0b6 100644
--- a/gitlab-templates/linux-qt6-static.yml
+++ b/gitlab-templates/linux-qt6-static.yml
@@ -1,13 +1,13 @@
-suse_tumbleweed_qt65_static:
+suse_tumbleweed_qt66_static:
   stage: build
-  image: invent-registry.kde.org/sysadmin/ci-images/suse-qt65:latest
+  image: invent-registry.kde.org/sysadmin/ci-images/suse-qt66:latest
   tags:
 - Linux
   variables:
-KDECI_CC_CACHE: /mnt/caches/suse-qt6.5-static/
-KDECI_CACHE_PATH: /mnt/artifacts/suse-qt6.5-static/
+KDECI_CC_CACHE: /mnt/caches/suse-qt6.6-static/
+KDECI_CACHE_PATH: /mnt/artifacts/suse-qt6.6-static/
 KDECI_GITLAB_SERVER: https://invent.kde.org/
-KDECI_PACKAGE_PROJECT: teams/ci-artifacts/suse-qt6.5-static
+KDECI_PACKAGE_PROJECT: teams/ci-artifacts/suse-qt6.6-static
   interruptible: true
   before_script:
 - git clone https://invent.kde.org/sysadmin/ci-utilities.git --depth=1
diff --git a/gitlab-templates/linux-qt6.yml b/gitlab-templates/linux-qt6.yml
index 71e5c03..5f0ef50 100644
--- a/gitlab-templates/linux-qt6.yml
+++ b/gitlab-templates/linux-qt6.yml
@@ -1,13 +1,13 @@
-suse_tumbleweed_qt65:
+suse_tumbleweed_qt66:
   stage: build
-  image: invent-registry.kde.org/sysadmin/ci-images/suse-qt65:latest
+  image: invent-registry.kde.org/sysadmin/ci-images/suse-qt66:latest
   tags:
 - Linux
   variables:
-KDECI_CC_CACHE: /mnt/caches/suse-qt6.5/
-KDECI_CACHE_PATH: /mnt/artifacts/suse-qt6.5/
+KDECI_CC_CACHE: /mnt/caches/suse-qt6.6/
+KDECI_CACHE_PATH: /mnt/artifacts/suse-qt6.6/
 KDECI_GITLAB_SERVER: https://invent.kde.org/
-KDECI_PACKAGE_PROJECT: teams/ci-artifacts/suse-qt6.5
+KDECI_PACKAGE_PROJECT: teams/ci-artifacts/suse-qt6.6
   interruptible: true
   before_script:
 - git clone https://invent.kde.org/sysadmin/ci-utilities.git --depth=1

Re: Bringing Glaxnimate into KDE

[Ben Cooksley]

On Tue, Oct 31, 2023 at 2:04 AM Carl Schwan  wrote:

> On Monday, October 30, 2023 11:43:47 AM CET Mattia Basaglia wrote:
> > Hi,
>
> Hi Matt,
>
> > I'm the maintainer of Glaxnimate (https://glaxnimate.mattbas.org/) a
> > vector graphics animation editor that has been integrated with kdenlive
> > through the MLT framework. I've been having talks with some of the
> > kdenlive devs and we came to the conclusion that it would be helpful to
> > bring Glaxnimate into KDE.
> >
> > With the help of jk from kdenlive, we've made the code reuse compliant,
> > and added some craft jobs to the CI.
> >
> > I would need some guidance on how to push this further.
>
> First thing first, make sure you have read https://manifesto.kde.org/
> commitments/  and
> https://manifesto.kde.org/benefits/
>
> Then you need to find a sponsor and this mailing list is indeed the right
> place
> to do that. I think someone from the Kdenlive team with whom you already
> interacted (e.g. jk) would be the best for this task. In none of them has
> the
> time, I can probably also help.
>
> Then create a sysadmin request to move your repo to the KDE infrastructure:
> https://phabricator.kde.org/maniphest/task/edit/form/2/
>
> And ask to get a KDE developer account in https://identity.kde.org  so
> you can
> keep your git write access to your project ;)
>

These should be done simultaneously, and the requests should refer to each
other (doesn't need a link, just a note in there that this is part of
$project incubation) so we can ensure they're both processed at the same
time.
While in most cases we pick up on these requests coming in simultaneously,
it has happened once or twice where people have lost access for a couple of
days as they didn't flag this.


>
> Cheers,
> Carl
>

Cheers,
Ben


>
> >
> > Thanks,
> >
> > Matt
>
>
>
>
>