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

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: KDE Gear 24.02 bug fix releases and next Gear releases

[Ben Cooksley]

On Mon, Feb 19, 2024 at 12:36 PM Albert Astals Cid  wrote:

> El divendres, 16 de febrer de 2024, a les 21:40:33 (CET), Heiko Becker va
> escriure:
> > On Tuesday, 30 January 2024 23:39:43 CET, Albert Astals Cid wrote:
> > > El dijous, 21 de desembre de 2023, a les 19:49:42 (CET), Heiko Becker
> va
> > >
> > > escriure:
> > >> On Tuesday, 28 November 2023 16:21:38 CET, Albert Astals Cid wrote:
> ...
> > >
> > > No one complained much so
> > >
> > > https://community.kde.org/Schedules/KDE_Gear_24.02_Schedule
> > > https://community.kde.org/Schedules/KDE_Gear_24.05_Schedule
> > > https://community.kde.org/Schedules/KDE_Gear_24.08_Schedule
> > >
> > > How does that sound?
> >
> > Works for me.
> > One thing I noticed is that 24.05.0 is planned to happen at the same day
> as
> > Plasma 6.0.90 (at least according to
> > https://community.kde.org/Schedules/Plasma_6) though.
>
> I'd say that's probably fine?
>
> What's everyone's opinon?
>

Should be fine I think, different groups of people involved so just need to
make sure the press releases don't step on each other too much.


>
> Cheers,
>   Albert
>

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

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

Re: Branching KDE Gear. When?

[Ben Cooksley]

On Wed, Jan 3, 2024 at 3:59 AM Albert Astals Cid  wrote:

> We have two options:
>
>  * Do it before RC1
>  * Do it after RC1
>
> Doing it before RC1 has the benefit that we start testing things that may
> break because of the new branch existing (CI, translations, etc).
>
> But since some of those will actually break we should do it relatively
> before
> the release that is on the 10th of January, so i'd vote this Friday the
> latest.
>
> Doing it before the RC1 has the issue that we allow Qt6 porting up to RC1
> and
> Qt6 porting is usually quite big and one would not want to have to mess
> with
> branches when doing big changes.
>
> Given that we have a RC2, i'd personally vote for branching [just] after
> RC1.
>
> What do you all think?
>

>From a CI perspective we have yet to set up any stable seed jobs for Qt 6,
which while fairly straightforward to do still requires a bit of setup work
to complete.

There are some changes to the CI system waiting in the wings (primarily
going to affect FreeBSD, but there is some impact to Linux too) however
those shouldn't make any difference to when RC1 branches.


>
> Cheers,
>   Albert
>

Cheers,
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: KDE 6 MegaRelease further dependencies

[Ben Cooksley]

On Fri, Nov 3, 2023 at 10:05 AM Albert Astals Cid  wrote:

> El dimecres, 1 de novembre de 2023, a les 18:55:43 (CET), Jonathan Riddell
> va
> escriure:
> > Me and Justin suggested a Matrix room to coordinate this but nobody
> seemed
> > interested, let me know if you'd like one.
>
> chat rooms are particularly not great to coordinate with people that have
> different availability times, a mailing list or an issue tracker are much
> better for that.
>
> > I'd like to make a Todo board of this somehow, what's the best way to do
> > that?
>
> As I mentioned we can just use the issue tracker of the release-service
> team
> (please can anyone not part of the team confirm if they can open issues
> there
> i'm unsure how teams work on gitlab?)
>

In case my other reply is missed, please see
https://invent.kde.org/teams/release-service/qt6-mega-release

People should be able to open issues.


>
> Cheers,
>   Albert
>

Cheers,
Ben


>
>
> >
> > Paul made one for Promo https://phabricator.kde.org/T16977
> >
> > Further dependencies that Justin pointed me to from Fedora chat
> > https://pagure.io/fedora-kde/SIG/issue/383#comment-878191
> >
> > = xdg-utils
> > External project part of Freedesktop
> > Latest release 2018 by
> > Current development happening by e.g. Meven and Harald for KF6 support
> > https://cgit.freedesktop.org/xdg/xdg-utils/
> > Not much activity on the mailing list called Portland (gosh I think I
> > remember that name being brought up)
> > https://lists.freedesktop.org/archives/portland/
> > I don't know who has authority to make a release
> >
> > = libaccounts-qt
> > External project
> > https://gitlab.com/accounts-sso/libaccounts-qt/
> > Last release 4 years ago
> > Git master builds for both Qt 5 and 6 thanks to Nico
> > No activity on the mailing list, it's not clear who can make a release of
> > this https://groups.google.com/g/accounts-sso-devel
> >
> > = gpgme
> > This is fine, current release builds for Qt 5 and 6, just remind distros
> to
> > package newest version
> >
> > = qca
> > Builds for Qt 5 and 6 for the last couple of releases, just remind
> distros
> > to package newest version
> >
> > = packagekit-qt
> > Current release builds for Qt 5 and 6, just remind distros to package
> > newest version
> >
> > = grantlee
> > This is now KTextTemplate and part of Frameworks so just release note
> that
> >
> > = signond
> > This seems to build for Qt 5 and 6 with no modifications so just release
> > note for distos to package it
> >
> > = signon-ui
> > I have no idea what's going on here, there were releases with ubunntu in
> > the version number in 2015 of something called "signon-ui"
> > https://gitlab.com/accounts-sso/signon-ui/-/tags
> > Now the project is called "signon-ui-qt" in gitlab at least and Nico is
> > going work on it so maybe it needs a release? We built it for Qt 5 in
> neon
> > and nobody has complained thus far.
> >
> > = signon-plugin-oauth2
> > Another one where it's not clear how releases are managed if at all
> > https://gitlab.com/accounts-sso/signon-plugin-oauth2/-/tags
> > Release 2 years ago uses Qt 5
> > No development since then, does it need work for Qt 6?
> >
> > = appstream
> > Not to be confused with the Amazon product of the same name or indeed
> > "upstream", this is an external project where Plasma needs 1.0 which
> isn't
> > released yet. Hopefully it'll be released in time for our final one in
> the
> > mean time tell distros to use git
> > https://www.freedesktop.org/wiki/Distributions/AppStream/
> >
> > = kweathercore
> > 0.7 released in sep 2022 should build against Qt 6, tell distros to
> update
> > their packages
> >
> > = libquotient
> > https://github.com/quotient-im/libQuotient/tags
> > Current release from september builds for both Qt 5 and 6, just remind
> > distros to update packaging.
> >
> > = kdsoap6
> > External project, Latest release builds with Qt 5 and 6 tell distros to
> > package it
> > https://github.com/KDAB/KDSoap/releases
> > kio-extras needs it so needs a Qt 5 build too for KF5 apps
> >
> > = kdsoap-ws-discovery-client
> > KDE project part of release service,
> > https://invent.kde.org/libraries/kdsoap-ws-discovery-client
> > New release will build with Qt 5 and 6
> > kio-extras needs it so needs a Qt 5 build as well as Qt 6 for KF5 apps
> >
> > = kio-extras
> > part of kde gear
> > KF5 apps need Qt 5 build as well as Qt 6 although there's lots of
> clashing
> > files
> >
> > = qcoro
> > https://github.com/danvratil/qcoro
> > Latest release can build for Qt 5 and 6, tell distros to package it for
> both
> >
> > = futuresql
> > KDE library https://invent.kde.org/libraries/futuresql
> > Latest release from May builds both Qt 5 and 6, tell distros to do both
> > https://download.kde.org/stable/futuresql/
> >
> > = kquickimageeditor
> > https://invent.kde.org/libraries/kquickimageeditor.git
> > A qml module needed for koko, skanpage, and neochat
> > Last release was in October 2021 by Carl
> > Master supports Qt 6, new release 

Re: KDE 6 MegaRelease further dependencies

[Ben Cooksley]

On Thu, Nov 2, 2023 at 6:56 AM Jonathan Riddell  wrote:

> Me and Justin suggested a Matrix room to coordinate this but nobody seemed
> interested, let me know if you'd like one.
>
> I'd like to make a Todo board of this somehow, what's the best way to do
> that?
>

We don't particularly have a good team to put a project in for this, is
this something you foresee needing many times more in the future?


>
> Paul made one for Promo https://phabricator.kde.org/T16977
>
> Further dependencies that Justin pointed me to from Fedora chat
> https://pagure.io/fedora-kde/SIG/issue/383#comment-878191
>
> = xdg-utils
> External project part of Freedesktop
> Latest release 2018 by
> Current development happening by e.g. Meven and Harald for KF6 support
> https://cgit.freedesktop.org/xdg/xdg-utils/
> Not much activity on the mailing list called Portland (gosh I think I
> remember that name being brought up)
> https://lists.freedesktop.org/archives/portland/
> I don't know who has authority to make a release
>
> = libaccounts-qt
> External project
> https://gitlab.com/accounts-sso/libaccounts-qt/
> Last release 4 years ago
> Git master builds for both Qt 5 and 6 thanks to Nico
> No activity on the mailing list, it's not clear who can make a release of
> this https://groups.google.com/g/accounts-sso-devel
>
> = gpgme
> This is fine, current release builds for Qt 5 and 6, just remind distros
> to package newest version
>
> = qca
> Builds for Qt 5 and 6 for the last couple of releases, just remind distros
> to package newest version
>
> = packagekit-qt
> Current release builds for Qt 5 and 6, just remind distros to package
> newest version
>
> = grantlee
> This is now KTextTemplate and part of Frameworks so just release note that
>
> = signond
> This seems to build for Qt 5 and 6 with no modifications so just release
> note for distos to package it
>
> = signon-ui
> I have no idea what's going on here, there were releases with ubunntu in
> the version number in 2015 of something called "signon-ui"
> https://gitlab.com/accounts-sso/signon-ui/-/tags
> Now the project is called "signon-ui-qt" in gitlab at least and Nico is
> going work on it so maybe it needs a release? We built it for Qt 5 in neon
> and nobody has complained thus far.
>
> = signon-plugin-oauth2
> Another one where it's not clear how releases are managed if at all
> https://gitlab.com/accounts-sso/signon-plugin-oauth2/-/tags
> Release 2 years ago uses Qt 5
> No development since then, does it need work for Qt 6?
>
> = appstream
> Not to be confused with the Amazon product of the same name or indeed
> "upstream", this is an external project where Plasma needs 1.0 which isn't
> released yet. Hopefully it'll be released in time for our final one in the
> mean time tell distros to use git
> https://www.freedesktop.org/wiki/Distributions/AppStream/
>
> = kweathercore
> 0.7 released in sep 2022 should build against Qt 6, tell distros to update
> their packages
>
> = libquotient
> https://github.com/quotient-im/libQuotient/tags
> Current release from september builds for both Qt 5 and 6, just remind
> distros to update packaging.
>
> = kdsoap6
> External project, Latest release builds with Qt 5 and 6 tell distros to
> package it
> https://github.com/KDAB/KDSoap/releases
> kio-extras needs it so needs a Qt 5 build too for KF5 apps
>
> = kdsoap-ws-discovery-client
> KDE project part of release service,
> https://invent.kde.org/libraries/kdsoap-ws-discovery-client
> New release will build with Qt 5 and 6
> kio-extras needs it so needs a Qt 5 build as well as Qt 6 for KF5 apps
>
> = kio-extras
> part of kde gear
> KF5 apps need Qt 5 build as well as Qt 6 although there's lots of clashing
> files
>
> = qcoro
> https://github.com/danvratil/qcoro
> Latest release can build for Qt 5 and 6, tell distros to package it for
> both
>
> = futuresql
> KDE library https://invent.kde.org/libraries/futuresql
> Latest release from May builds both Qt 5 and 6, tell distros to do both
> https://download.kde.org/stable/futuresql/
>
> = kquickimageeditor
> https://invent.kde.org/libraries/kquickimageeditor.git
> A qml module needed for koko, skanpage, and neochat
> Last release was in October 2021 by Carl
> Master supports Qt 6, new release needed
>
> = qtkeychain
> External project used by tokodon, plasmatube, neochat, kmail, kasts and
> libquotient
> https://github.com/frankosterfeld/qtkeychain/releases
> Releases since May have Qt 6 support, tell distros to package for both Qt
> 5 and 6 (or drop the Qt 5 depends)
>
> = pulseaudio-qt
> https://invent.kde.org/libraries/pulseaudio-qt.git
> KDE library used by KDE connect
> Last release 2021 by Nicolas Fella
> master supports Qt 5 and 6 since last year
> KDE connect looks like it also builds for Qt5 and 6 so this could do with
> a new release pronto
>
> = wayland-protocols
> Fedora said this needed an update, I'm not sure that it does
>
> = kirigami-addons
> Not on Fedora's list
> various QML modules used by various things
> Carl released 

Re: print-manager and wacomtablet to Plasma

[Ben Cooksley]

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

> As discuccsed in Plasma meeting and just now with KDE gear release spods,
> Plasma would like to take over releases of print-manager and wacomtablet.
> This means renumbering the tars from e.g. 23.08 to 5.80.0.
>

Isn't this going to cause distributions all sorts of pain as package
managers are going to assume 23.08 > 5.80 and refuse to update?


>
> Any issues?
>
> Jonathan
>
>
Cheers,
Ben

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

Re: KDE Gear repositories switching to Qt6 - Re: Release schedule proposal for the February MegaRelease

[Ben Cooksley]

On Tue, Sep 26, 2023 at 11:32 AM Albert Astals Cid  wrote:

> El dimarts, 26 de setembre de 2023, a les 0:28:15 (CEST), Albert Astals
> Cid va
> escriure:
> > https://community.kde.org/Schedules/February_2024_MegaRelease
> >
> > Beta 1 is during Qt World Summit that is not ideal but I guess doable?
> >
> > I'll answer to this email with a few other emails things i thing we have
> to
> > discuss to try to organize the discusion earlier.
>
> Until how kate do we allow KDE Gear repositories to switch to Qt6?
>
> I'd vote for "need to be ready for RC1".
>

Sorry not quite sure what the question is here?

If what you were meaning was "at what point do we consider a Qt 6 version
suitable for release" - then it being of release candidate quality would be
a good signpost / line in the sand I think.


> Opinions?
>
> Cheers,
>   Albert
>

Cheers,
Ben


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

Re: A few rules when moving master branches to Qt6

[Ben Cooksley]

On Sat, Sep 16, 2023 at 7:54 AM Luigi Toscano 
wrote:

> Hi all,
>

Hi all,


>
> in order to reduce the burden on us (translation team), as we need to move
> the
> translation to a different branch, I kindly ask all of you to respect a few
> simple rules when moving the master branch to a repository to Qt6 only:
>
> 1- preferibly send a merge request to sysadmin/repo-metadata mentioning the
> localization team, and after getting a proper review, please wait for us
> (translation) to merge it and move the translations at the right time
>
> 2- if you commit directly to sysadmin/repo-metadata, please do it between
> 5.00
> UTC and 16.00 UTC: we can't always ensure to be around to handle the
> translations before scripty runs.
>
> 3- it would be better if those changes would be avoided over the weekend.
> If
> in doubt, please ping us and see if we are around.
>
> Rule number 2 is the one I'd like to have more strictly followed, the
> others
> are more "nice to have".
>

Just one small addendums to this:

4) Please also check sysadmin/ci-management to see if the project you are
making Qt 6 only is part of a CI seed build. If it is you will need to
update accordingly (removing, adding or updating branches as appropriate).


>
> Thanks!
>
> --
> Luigi
>

Cheers,
Ben

General Availability - Updated Gitlab Runners

[Ben Cooksley]

Hi all,

Today we deployed replacements to node3, node4 and node5 - which were the
remaining old workers attached to Invent.

This means that all workers have now completed being updated to a more
modern host operating system (Ubuntu 22.04) as well as newer generation
hardware (with the CPU now being a Ryzen 7700 compared to the previous
Ryzen 3700X).

Windows builds have also been moved over, with the only change there being
a reduction from 24GB RAM to 16GB RAM being allocated to Windows on those
three nodes. Windows Server 2022 Datacenter Edition continues to be used as
the host OS for those builds.

The legacy builders are still currently performing FreeBSD builds, however
I will provision those FreeBSD VMs shortly so they should transition across
soon as well.

Please let us know if there are any issues.

Cheers,
Ben

New CI workers - node1 and node2

[Ben Cooksley]

Hi all,

Over the last 2 days i've been busy connecting two new CI workers to
GitLab, which are the beginning of long overdue improvements to our CI
arrangements needed to support the final retirement of the Binary Factory.

While developers shouldn't notice much in the way of changes, this will
bring us a series of long term benefits which include:
- The builders host OS being significantly more up to date, which will
allow certain GPU related tests to be run again
- The ability to build Webengine on the CI system (for Craft caches
primarily) which will support our builds of Linux appimages
- Reduced time to wait for a build to start as more build resources will be
available to Gitlab (while we've had 5 workers for a long time, 2 were
connected to the Binary Factory and were unavailable to Gitlab)

On the Linux and Windows side, the two new builders - node1 and node2 - are
already available and should be carrying out builds already.
I'm still waiting on some details for FreeBSD, but once that has been
sorted we should be able to provision those as well.

For those curious, these two builders (node1 and node2) are equipped with
Ryzen 7 7700 CPUs, 128GB RAM and 1TB of Gen4 NVMe storage, although not all
of this is available to Linux builds as it is apportioned partly to Windows
and FreeBSD VMs.

Once these two machines are in full service, two of the current nodes
(node3 and node4) will be retired to allow them to be replaced with newer
machines as the Binary Factory shutdown approaches (watch this space).

Thanks,
Ben

Re: ACTION REQUIRED - Gitlab and Subversion server migration

[Ben Cooksley]

On Tue, Jul 25, 2023 at 1:35 AM Vít Pelčák  wrote:

>
> ne 23. 7. 2023 v 12:01 odesílatel Ben Cooksley  napsal:
>
>> Good morning KDE Developers,
>>
>> As many of you will be aware, today Gitlab and our Subversion repository
>> were both migrated to a new home - on a more modern and more powerful
>> server, which should better support future work.
>>
>> As a consequence the host key of the server has now changed, which means
>> you will need to take steps on your system otherwise you won't be allowed
>> to connect to the new server.
>>
>> Please ensure you run the following two commands to clear out any
>> existing host keys:
>> - ssh-keygen -R invent.kde.org -f ~/.ssh/known_hosts
>> - ssh-keygen -R svn.kde.org ~/.ssh/known_hosts
>>
>
> I suppose you meant
> ssh-keygen -R svn.kde.org -f ~/.ssh/known_hosts
>

That is correct.


>
> right?
>
>
Cheers,
Ben

ACTION REQUIRED - Gitlab and Subversion server migration

[Ben Cooksley]

Good morning KDE Developers,

As many of you will be aware, today Gitlab and our Subversion repository
were both migrated to a new home - on a more modern and more powerful
server, which should better support future work.

As a consequence the host key of the server has now changed, which means
you will need to take steps on your system otherwise you won't be allowed
to connect to the new server.

Please ensure you run the following two commands to clear out any existing
host keys:
- ssh-keygen -R invent.kde.org -f ~/.ssh/known_hosts
- ssh-keygen -R svn.kde.org ~/.ssh/known_hosts

Following these commands the next time you try to connect you will be
prompted to confirm the new host key and trust it for use. For those who
would like to confirm that host key, it is as follows:

256 SHA256:zHdK2R/S6s5Oj71N0s8LHWCXXsUt+DCztd+GjzW9KlU root@lerwini
(ED25519)
256 SHA256:ZNBg4AkRxbt/N6xzpt7GbmmS78A3WFy5lz0l/cPHbcE root@lerwini (ECDSA)
3072 SHA256:KxAoV6VsbKvAocFZCJlxtmPDScmUCRNiUiOCSXNSC/k root@lerwini (RSA)

Please let us know, via either sysad...@kde.org or kde-de...@kde.org if you
encounter any issues with the new system.

Many thanks,
Ben Cooksley
KDE Sysadmin

Downtime notification - Gitlab server migration

[Ben Cooksley]

Good morning all,

This evening (UTC time) I will be moving Gitlab from the current system it
is located on to a new server.

This move is being undertaken to ensure we have the most up to date
software stack, as well as take advantage of newer hardware that is both
more efficient and more powerful (the existing server is around 4 years old
or so).

Based on performance benchmarks, the new system should have a significant
performance uplift, which will help ensure we're able to support new
workloads - such as the incoming migration of binary build jobs from the
Binary Factory.

This migration will take several hours unfortunately, during which time
Gitlab will be completely unavailable. This includes read and write
operations to Git repositories, authentication services for KDE.org sites
that use Invent login, issues, wiki pages and everything else hosted by
Gitlab.

This migration will be undertaken from approximately 10pm UTC, Saturday
22nd July.

Please let me know if you have any questions on the above.

Cheers,
Ben

Re: Suggestion to drop ktp from KDE Gear

[Ben Cooksley]

On Thu, Jun 22, 2023 at 4:35 AM Jonathan Riddell  wrote:

> I'd like to suggest dropping ktp packages from the next KDE Gear release.
> Telepathy upstream is unmaintained, KTP is unmaintained and discussions
> with one of the original authors says it should be dropped.
>
> Modules we release are:
> ktp-accounts-kcm
> ktp-approver
> ktp-auth-handler
> ktp-call-ui
> ktp-common-internals
> ktp-contact-list
> ktp-contact-runner
> ktp-desktop-applets
> ktp-filetransfer-handler
> ktp-kded-module
> ktp-send-file
> ktp-text-ui
>
> Previously discussed in 2017
> https://mail.kde.org/pipermail/release-team/2017-August/010494.html
>

If the overall stack it builds on top of is also unmaintained, then it
makes logical sense to drop our parts of it as well.

+1 from my side.


> https://www.mail-archive.com/release-team@kde.org/msg10454.html
>
> Jonathan
>
>
Thanks,
Ben

Re: kio-extras and the KF5/KF6 period

[Ben Cooksley]

On Wed, Jun 21, 2023 at 8:22 PM Harald Sitter  wrote:

> On Tue, Jun 20, 2023 at 11:23 PM Sune Vuorela  wrote:
> >
> > On 2023-06-20, David Redondo  wrote:
> > > Harald and I prototyped another solution to build a Qt
> > >  5 and Qt 6 version out of the same repo and employed it on
> > > plasma-integration:
> https://invent.kde.org/plasma/plasma-integration/-/
> > > merge_requests/91
> >
> > Did I miss something or is this just branching but without having git to
> > help us move stuff between versions?
>
> Yes but no. If we have two branches we also need two tars and everyone
> needs to do two things. If we have everything in the same branch then
> everything is as usual. Also, the sources are so divergent that
> picking is bound to be annoying.
>

It sounds like we are approaching (or have already hit) a "crossroads"
where it is time for the Qt 5 codebase to enter a stable release only
phase, with master becoming Qt 6 exclusive.
Splitting the code into separate Qt 5 / Qt 6 folders sounds like it will be
difficult to ensure that all bug fixes are applied equally to both sides.


>
> HS
>

Cheers,
Ben

Re: Gitlab Downtime

[Ben Cooksley]

On Tue, Apr 11, 2023 at 9:23 PM Ben Cooksley  wrote:

> Hi all,
>
> Tomorrow I will need to conduct some maintenance on our Gitlab instance
> which may take approximately 60 to 90 minutes in time, depending on how
> things go.
>
> This downtime is needed to facilitate the update of several components
> that Gitlab relies upon, including the underlying Ruby interpreter and will
> pave the way for us to migrate to a newer version of GitLab in the coming
> days - as well as a replacement GitLab server (which can now be considered
> as GitLab have finally moved to using Ruby 3).
>
> All going well, i'm hopeful the maintenance will take significantly less
> time than i'm allowing for here.
>
> Maintenance will start at approximately 1930 NZST ( 0730 UTC ) on 11
> April, during which time all services associated with Gitlab (including SSO
> login, Git repositories, etc) will be unavailable.
>

Small typo correction here: 12 April, ie. tomorrow.


>
> Apologies in advance for the disruption.
>
> Many thanks,
> Ben
>

Thanks,
Ben

Gitlab Downtime

[Ben Cooksley]

Hi all,

Tomorrow I will need to conduct some maintenance on our Gitlab instance
which may take approximately 60 to 90 minutes in time, depending on how
things go.

This downtime is needed to facilitate the update of several components that
Gitlab relies upon, including the underlying Ruby interpreter and will pave
the way for us to migrate to a newer version of GitLab in the coming days -
as well as a replacement GitLab server (which can now be considered as
GitLab have finally moved to using Ruby 3).

All going well, i'm hopeful the maintenance will take significantly less
time than i'm allowing for here.

Maintenance will start at approximately 1930 NZST ( 0730 UTC ) on 11 April,
during which time all services associated with Gitlab (including SSO login,
Git repositories, etc) will be unavailable.

Apologies in advance for the disruption.

Many thanks,
Ben

CI Outage

[Ben Cooksley]

Hi all,

As many of you will have noticed, the Linux side of our Gitlab CI setup,
including those runs for Android and other miscellaneous jobs (such as
cppcheck) were all KO yesterday due to a Docker error.

This has now been corrected, and was due to a defect in an update shipped
by the Docker upstream maintainers. They added a hard dependency on an
Apparmor CLI tool, however failed to add the corresponding dependency to
their packages (and to top matters off, part of that package is kernel side
and only does it's initialisation on system boot...)

The nodes have now had their setups corrected and have been rebooted, and
everything is back in service. I have also kicked off builds of just about
everything that is failing on the CI system.

Apologies for the disruption here.

While doing so I noticed a fairly sad number of actual
failures-to-build-from-source:
- Mandatory X11 dependency on Windows:
https://invent.kde.org/utilities/keditbookmarks
- Blind KF6 porting: https://invent.kde.org/pim/kontact/-/jobs/786385
- (and others yet to finish working their way through)

It also looks like we have some packages that are not being rebuilt by seed
jobs (see https://invent.kde.org/pim/kalendar/-/jobs/786366), so once the
system has finished playing catch up we may need to do some additional
infrastructure work there.

Please contact me if you'd like to assist with that.

Thanks,
Ben

Re: releases driven through invent?

[Ben Cooksley]

On Fri, Oct 21, 2022 at 2:44 AM Harald Sitter  wrote:

> Servas,
>

Hi Harald,


>
> I've been pondering a bit what releases should look like in this brave
> new world we are in, with po data inside repos, and would like to
> propose the following:
>
> - new releaseme program; run with `--version 1.0.0 --ref master
> plasma-workspace`
> - tells invent to make a release with tag v1.0.0.0 (the terminal zero
> is managed by the program? through inspecting existing tags)
> - downloads tarball
> - GPG signs it
> - uploads all artifacts to download.kde.org (with chown?) to $scope/1.0.0/
>

Just to be sure we're all on the same page, are you talking about making
use of https://docs.gitlab.com/ee/user/project/releases/?

I'm not sure it is best that we upload tags prior to making the release
public, but for those independently released projects that go public
immediately the workflow you are describing below should work.
By uploading all artifacts I assume you are referring to
ftp://upload.kde.org?


>
> - distros package stuff. find issues
> - program is run again with `--version 1.0.0 --ref master
> plasma-workspace` to respin
> - same publishing dance as before but now with v1.0.0.1
>
> - release step can be repeated any number of times. always
> incrementing the implicit fourth version element.
>
> Obviously ref could also be a stable branch or indeed a release branch
> specifically for spinning the release off of e.g. think a Plasma/1.0.0
> branch whose sole purpose is to cherry pick into and release from -
> not saying we should do it that way, but it's an option.
>
> The primary complication here is that since invent releases are based
> on tags we'd need to tag each respin. That could actually work in our
> favor though. A while ago Nate proposed that we do micro patch
> releases instead of asking distros to package patches - that would be
> just like a respin in this new world order. So, e.g. at release time
> of Plasma 1.0.0 the actual tarball of plasma-workspace may be
> 1.0.0.25, a critical bugfix may then land as 1.0.0.26 in that same
> directory a couple hours later. The only difference would be that the
> previous 25 respins were done while the 1.0.0 dir was private, and .26
> happened after it was published.
>
> Thoughts? Other complications I've not foreseen yet?
>
> HS
>

Cheers,
Ben

Re: Gitlab CI Dashboards and retirement of build.kde.org

[Ben Cooksley]

On Sun, Sep 4, 2022 at 8:51 PM Gilles Caulier 
wrote:

> Hi Ben,
>

HI Gilles,


>
> With build/binary-factory , it was possible to get an Embeddable Build
> Status Icon as this one :
>
>
> https://binary-factory.kde.org/view/AppImage/job/Digikam_Nightly_appimage-centos7/badge/
>
> Does this feature still exist with Gitlab infrastructure ?
>

Yes, quoting my earlier email:

[quote]
Gitlab provides a limited selection of badges - which can be found at:
- https://invent.kde.org/multimedia/kdenlive/badges/master/pipeline.svg
- https://invent.kde.org/multimedia/kdenlive/badges/master/coverage.svg
- https://invent.kde.org/multimedia/kdenlive/-/badges/release.svg
[/quote]

You'll need to swap multimedia/kdenlive to graphics/digikam but otherwise
that should work fine.

Please note that the Binary Factory is not impacted by this, so anything
relating to the Binary Factory is unchanged at this time.


>
> Thanks
>
> Gilles
>

Regards,
Ben


>
> Le sam. 27 août 2022 à 11:45, Ben Cooksley  a écrit :
> >
> > Hi all,
> >
> > This evening I completed the necessary setup required to complete our
> Gitlab CI dashboards, which can now be found at
> https://metrics.kde.org/dashboards/f/aNxvXJW4k/gitlab-ci (KDE Developer
> account login required)
> >
> > These allow any developer to get a view on the current CI status of
> projects and groups of projects on a branch and platform basis - and should
> hopefully provide useful insight into the overall status that can currently
> be obtained from Jenkins.
> >
> > As this was the last thing holding us back from shutting down
> build.kde.org, i'd like to proceed with retiring and shutting down
> build.kde.org as soon as possible so the capacity it occupies can be
> released and reallocated to Gitlab.
> >
> > If anyone would like to experiment with customised views for their own
> purposes (where the above provided ones are insufficient) please file a
> Sysadmin ticket.
> >
> > Please let me know if there are any questions on the above.
> >
> > Thanks,
> > Ben
>

Re: Gitlab CI Dashboards and retirement of build.kde.org

[Ben Cooksley]

On Sun, Sep 4, 2022 at 7:54 AM Johnny Jazeix  wrote:

>
>
> Le sam. 3 sept. 2022 à 21:28, Ben Cooksley  a écrit :
>
>> On Sat, Sep 3, 2022 at 9:29 PM Gleb Popov <6year...@gmail.com> wrote:
>>
>>> On Sat, Sep 3, 2022 at 7:46 AM Ben Cooksley  wrote:
>>> >
>>> > As previously indicated, I have now shutdown build.kde.org along with
>>> the domain that supported it's version of the CI tooling.
>>> > The repository containing that tooling has now also been archived, and
>>> the former build.kde.org domain has been redirected to metrics.kde.org.
>>> >
>>> > The server which was acting as a builder for build.kde.org will be
>>> rebuilt in the coming days and reallocated to support Gitlab CI workloads.
>>> >
>>> > Thanks,
>>> > Ben
>>>
>>> What should be used instead of binary-factory? How do I transform this
>>> link?
>>>
>>>
>>> https://binary-factory.kde.org/view/Windows%2064-bit/job/Kate_Release_win64/1762/artifact/kate-22.08.0-1762-windows-msvc2019_64-cl.exe
>>
>>
>> At this time the Binary Factory is not impacted by this.
>>
>> Regards,
>> Ben
>>
>
> Hi,
>
> I think the issue mentioned by Glen is that this link (and all other
> artifacts from binary-factory) is redirected to
> https://build-artifacts.kde.org/binary-factory/Kate_Release_win64/1762/kate-22.08.0-1762-windows-msvc2019_64-cl.exe
> which does not exist.
>

Oops. That is an oversight on my part - apologies - and has now been
corrected (although the URLs will have changed)

Cheers,
Ben


>
>
> Cheers,
> Johnny
>

Re: Gitlab CI Dashboards and retirement of build.kde.org

[Ben Cooksley]

On Sun, Sep 4, 2022 at 2:13 AM Michael Reeves  wrote:

> I now have no way to even test macosx builds for kdiff3, I have no access
> to a 64bit Intel mac. What are the plans for this and Windows
> builds. I have a functional windows based craft installed locally.
>

At this time the Binary Factory is unaffected by these changes, however
steps will be made in the coming weeks/months to migrate away from the
Binary Factory to equivalent Gitlab jobs (although they won't be available
for Merge Requests due to various technical limitations)

Regards,
Ben


>
>
> Sep 3, 2022 12:47:06 AM Ben Cooksley :
>
> On Sat, Aug 27, 2022 at 9:44 PM Ben Cooksley  wrote:
>
>> Hi all,
>>
>> This evening I completed the necessary setup required to complete our
>> Gitlab CI dashboards, which can now be found at
>> https://metrics.kde.org/dashboards/f/aNxvXJW4k/gitlab-ci (KDE Developer
>> account login required)
>>
>> These allow any developer to get a view on the current CI status of
>> projects and groups of projects on a branch and platform basis - and should
>> hopefully provide useful insight into the overall status that can currently
>> be obtained from Jenkins.
>>
>> As this was the last thing holding us back from shutting down
>> build.kde.org, i'd like to proceed with retiring and shutting down
>> build.kde.org as soon as possible so the capacity it occupies can be
>> released and reallocated to Gitlab.
>>
>
> As previously indicated, I have now shutdown build.kde.org along with the
> domain that supported it's version of the CI tooling.
> The repository containing that tooling has now also been archived, and the
> former build.kde.org domain has been redirected to metrics.kde.org.
>
> The server which was acting as a builder for build.kde.org will be
> rebuilt in the coming days and reallocated to support Gitlab CI workloads.
>
>
>>
>> If anyone would like to experiment with customised views for their own
>> purposes (where the above provided ones are insufficient) please file a
>> Sysadmin ticket.
>>
>> Please let me know if there are any questions on the above.
>>
>> Thanks,
>> Ben
>>
>
> Thanks,
> Ben
>
>

Re: Gitlab CI Dashboards and retirement of build.kde.org

[Ben Cooksley]

On Sat, Sep 3, 2022 at 9:29 PM Gleb Popov <6year...@gmail.com> wrote:

> On Sat, Sep 3, 2022 at 7:46 AM Ben Cooksley  wrote:
> >
> > As previously indicated, I have now shutdown build.kde.org along with
> the domain that supported it's version of the CI tooling.
> > The repository containing that tooling has now also been archived, and
> the former build.kde.org domain has been redirected to metrics.kde.org.
> >
> > The server which was acting as a builder for build.kde.org will be
> rebuilt in the coming days and reallocated to support Gitlab CI workloads.
> >
> > Thanks,
> > Ben
>
> What should be used instead of binary-factory? How do I transform this
> link?
>
>
> https://binary-factory.kde.org/view/Windows%2064-bit/job/Kate_Release_win64/1762/artifact/kate-22.08.0-1762-windows-msvc2019_64-cl.exe


At this time the Binary Factory is not impacted by this.

Regards,
Ben

Re: Gitlab CI Dashboards and retirement of build.kde.org

[Ben Cooksley]

On Sat, Aug 27, 2022 at 9:44 PM Ben Cooksley  wrote:

> Hi all,
>
> This evening I completed the necessary setup required to complete our
> Gitlab CI dashboards, which can now be found at
> https://metrics.kde.org/dashboards/f/aNxvXJW4k/gitlab-ci (KDE Developer
> account login required)
>
> These allow any developer to get a view on the current CI status of
> projects and groups of projects on a branch and platform basis - and should
> hopefully provide useful insight into the overall status that can currently
> be obtained from Jenkins.
>
> As this was the last thing holding us back from shutting down
> build.kde.org, i'd like to proceed with retiring and shutting down
> build.kde.org as soon as possible so the capacity it occupies can be
> released and reallocated to Gitlab.
>

As previously indicated, I have now shutdown build.kde.org along with the
domain that supported it's version of the CI tooling.
The repository containing that tooling has now also been archived, and the
former build.kde.org domain has been redirected to metrics.kde.org.

The server which was acting as a builder for build.kde.org will be rebuilt
in the coming days and reallocated to support Gitlab CI workloads.


>
> If anyone would like to experiment with customised views for their own
> purposes (where the above provided ones are insufficient) please file a
> Sysadmin ticket.
>
> Please let me know if there are any questions on the above.
>
> Thanks,
> Ben
>

Thanks,
Ben

Re: Copying po/docbook files to repositories nightly

[Ben Cooksley]

On Sat, Sep 3, 2022 at 9:24 AM Albert Astals Cid  wrote:

> As you may know, translations for apps don't live in the same place as the
> code for the apps themselves.
>
> This greatly benefits translators but is not awesome for the release
> management
> side of things since it means that for each release we need to not forget
> to
> copy the appropriate files to the appropriate place, makes tagging
> somewhat
> harder, etc.
>
> For a while now we have been running an "experimental" copy-po-qm-docbook-
> back-to-repository in a number of "select" repositories and it seems to
> have
> worked quite well, you can seem one example in
> https://invent.kde.org/plasma-mobile/alligator/-/commits/master/po
>
> The idea is to enable this for all repositories.
>
> This is a heads up, as a developer there's nothing you need to do, at most
> remove the po/ folder from .gitignore if for some reason it is there.
>
> If you're a packager you will need to make sure your scripts don't try to
> copy
> po/qm/docbook files anymore when doing a release once this is activated.
>
> My plan would be to enable this scripts over Akademy so we have the high
> bandwidth there to fix things if needed.
>
> Opinions? Comments?
>

I'm very happy to see this change finally start to roll out - being
something that was last discussed back in MIlian I believe!

Looking forward to it rolling out as it will mean we can start including
translations in nightly builds and will no longer have such a high
release-day load on our systems.



> Cheers,
>   Albert
>
>
>
Cheers,
Ben

Re: Copying po/docbook files to repositories nightly

[Ben Cooksley]

On Sat, Sep 3, 2022 at 11:02 AM Ömer Fadıl USTA  wrote:

> Just wanted to learn one thing , isn't this will populate the logs with
> lots of entries on git log history ?
>

The history already receives a number of commits from scripty relating to
updates made to *.desktop files, but yes it will involve additional commits
being made.
They would only impact po/ and poqm/ folders, which you can be easily
excluded if you have a local copy.


> I mean right now I am tracking git changes based on changes in history but
> this will add a new entry
> each night or I understand this wrong ?
>

It will add a commit each day there is an update to the translations -
which may be every night, but is not guaranteed to be the case.


> Also wouldn't it be possible to fetch related translation on the fly from
> the software side after releases ?
>
I mean translation of language X might be getting a little back lets say
> 5.26 released but team X
> might be late to complete their translation on time but user should have
> chance to download it
> after the release of it (without waiting for the next tagging ). Wouldn't
> it be possible to download and install the latest
> language data in applications just like users do with themes?
>

Users currently have to wait for releases to receive updates to
translations (among many other things) so this represents no change to what
we do currently.
Also, from an infrastructural perspective i'm very much opposed to this -
and there are numerous corner cases (such as string changes which while
rare do happen in stable from time to time) which could lead to various
breakages in the software itself.


>
> Thank you
>
> Ömer Fadıl Usta
> PGP key : 0xfd11561976b1690b
> about.me/omerusta
>

Cheers,
Ben


>
>
>
> Albert Astals Cid , 3 Eyl 2022 Cmt, 00:25 tarihinde şunu
> yazdı:
>
>> As you may know, translations for apps don't live in the same place as
>> the
>> code for the apps themselves.
>>
>> This greatly benefits translators but is not awesome for the release
>> management
>> side of things since it means that for each release we need to not forget
>> to
>> copy the appropriate files to the appropriate place, makes tagging
>> somewhat
>> harder, etc.
>>
>> For a while now we have been running an "experimental" copy-po-qm-docbook-
>> back-to-repository in a number of "select" repositories and it seems to
>> have
>> worked quite well, you can seem one example in
>> https://invent.kde.org/plasma-mobile/alligator/-/commits/master/po
>>
>> The idea is to enable this for all repositories.
>>
>> This is a heads up, as a developer there's nothing you need to do, at
>> most
>> remove the po/ folder from .gitignore if for some reason it is there.
>>
>> If you're a packager you will need to make sure your scripts don't try to
>> copy
>> po/qm/docbook files anymore when doing a release once this is activated.
>>
>> My plan would be to enable this scripts over Akademy so we have the high
>> bandwidth there to fix things if needed.
>>
>> Opinions? Comments?
>>
>> Cheers,
>>   Albert
>>
>>
>>

Re: Gitlab CI Dashboards and retirement of build.kde.org

[Ben Cooksley]

On Mon, Aug 29, 2022 at 12:45 AM Julius Künzel <
jk.kde...@smartlab.uber.space> wrote:

> Yes, it looks great!
>
> I wonder wether it makes sense to also display the test status in addition
> to the overall CI status? I guess the "CI failure on test failure option"
> is not enabled everywhere.
>

I'm afraid the Prometheus Gitlab CI exporter we are using doesn't support
collecting that data, so it isn't possible to do so.


>
>
> Cheers,
> Julius
>

Cheers,
Ben

Re: Gitlab CI Dashboards and retirement of build.kde.org

[Ben Cooksley]

On Sun, Aug 28, 2022 at 4:40 AM Albert Astals Cid  wrote:

> El dissabte, 27 d’agost de 2022, a les 11:44:47 (CEST), Ben Cooksley va
> escriure:
> > Hi all,
> >
> > This evening I completed the necessary setup required to complete our
> > Gitlab CI dashboards, which can now be found at
> > https://metrics.kde.org/dashboards/f/aNxvXJW4k/gitlab-ci (KDE Developer
> > account login required)
> >
> > These allow any developer to get a view on the current CI status of
> > projects and groups of projects on a branch and platform basis - and
> should
> > hopefully provide useful insight into the overall status that can
> currently
> > be obtained from Jenkins.
> >
> > As this was the last thing holding us back from shutting down
> build.kde.org,
> > i'd like to proceed with retiring and shutting down build.kde.org as
> soon
> > as possible so the capacity it occupies can be released and reallocated
> to
> > Gitlab.
> >
> > If anyone would like to experiment with customised views for their own
> > purposes (where the above provided ones are insufficient) please file a
> > Sysadmin ticket.
> >
> > Please let me know if there are any questions on the above.
>
> Looks great.
>

Yay!


>
> One thing that i'm not sure i understand correctly, currently in the
> General
> Overview, it says that there are 3 projects currently failing kwin,
> kpackage
> and kphotoalbum, but then if i go to the Per Platform View i get that
> rkward
> is failing on windows. Shouldn't rkward also be listed as failing on the
> general overview?
>

That is a rather curious bug, caused by the fact it was looking at things
on a Pipeline vs. Job basis.

The query you were looking at was looking at the list of most recent
pipeline runs on a per project basis, which in the case of rkward means the
last push by scripty - which was skipped (so not a failure).
I've tweaked the query to look at things on a per job basis now, which
skips over that issue.


>
> Cheers,
>   Albert
>

Cheers,
Ben


>
> >
> > Thanks,
> > Ben
>
>
>
>
>

Gitlab CI Dashboards and retirement of build.kde.org

[Ben Cooksley]

Hi all,

This evening I completed the necessary setup required to complete our
Gitlab CI dashboards, which can now be found at
https://metrics.kde.org/dashboards/f/aNxvXJW4k/gitlab-ci (KDE Developer
account login required)

These allow any developer to get a view on the current CI status of
projects and groups of projects on a branch and platform basis - and should
hopefully provide useful insight into the overall status that can currently
be obtained from Jenkins.

As this was the last thing holding us back from shutting down build.kde.org,
i'd like to proceed with retiring and shutting down build.kde.org as soon
as possible so the capacity it occupies can be released and reallocated to
Gitlab.

If anyone would like to experiment with customised views for their own
purposes (where the above provided ones are insufficient) please file a
Sysadmin ticket.

Please let me know if there are any questions on the above.

Thanks,
Ben

Re: KDE Frameworks 5.94.0

[Ben Cooksley]

On Sat, May 21, 2022 at 8:38 PM Albert Astals Cid  wrote:

> El dimarts, 17 de maig de 2022, a les 8:53:16 (CEST), Ben Cooksley va
> escriure:
> > On Tue, May 17, 2022 at 10:10 AM Albert Astals Cid 
> wrote:
> >
> > > El dilluns, 16 de maig de 2022, a les 11:50:13 (CEST), Ben Cooksley va
> > > escriure:
> > > > On Mon, May 16, 2022 at 9:39 AM Albert Astals Cid 
> wrote:
> > > >
> > > > > El diumenge, 15 de maig de 2022, a les 23:03:27 (CEST), David
> Faure va
> > > > > escriure:
> > > > > > On samedi 14 mai 2022 20:48:55 CEST Albert Astals Cid wrote:
> > > > > > > El diumenge, 8 de maig de 2022, a les 0:11:35 (CEST), David
> Faure
> > > va
> > > > > escriure:
> > > > > > > > On samedi 7 mai 2022 18:38:44 CEST Antonio Rojas wrote:
> > > > > > > > > El sábado, 7 de mayo de 2022 15:31:17 (CEST), David Faure
> > > escribió:
> > > > > > > > > > Dear packagers,
> > > > > > > > > >
> > > > > > > > > > KDE Frameworks 5.94.0 has been uploaded to the usual
> place.
> > > > > > > > > >
> > > > > > > > > > New frameworks: none this time.
> > > > > > > > >
> > > > > > > > > This should have been a reply to this mail of course
> > > > > > > > >
> > > > > > > > > >  tr tt ug uk and uz translations are missing from all
> > > tarballs.
> > > > > > > >
> > > > > > > > Thanks for noticing. My "update l10n" script did show an
> error
> > > about
> > > > > that
> > > > > > > > but I didn't see that error and moved on. I have now improved
> > > things
> > > > > so I
> > > > > > > > can't launch the next step if this step failed.
> > > > > > > >
> > > > > > > > I now uploaded new tarballs (also including
> > > > > > > > https://invent.kde.org/frameworks/
> > > > > plasma-framework/-/merge_requests/523)
> > > > > > > >
> > > > > > > > I hope it's all fine now, let me know otherwise.
> > > > > > >
> > > > > > > I've just realized that the packages dependencies have not been
> > > > > increased to
> > > > > > > 5.94 and they are just at 5.93. I guess that's not that bad,
> but
> > > just
> > > > > want
> > > > > > > to make sure that doesn't mean some other change may be also
> > > missing?
> > > > > >
> > > > > > Good catch. Fortunately nothing else should be missing. The
> reason
> > > this
> > > > > didn't happen is that I run
> > > > > >
> > > > > > cd ../src && ./kdesrc-build --src-only && cd ../release-tools &&
> > > > > ./list_frameworks.sh && ./update_l10n.sh &&
> > > > > ./increase_frameworks_version.sh step2
> > > > > >
> > > > > > and update_l10n failed because anonsvn threw me out in the
> middle of
> > > it.
> > > > > > I didn't notice, ran the next step (./make_rc_tag.sh) and this is
> > > how we
> > > > > got tags with missing languages.
> > > > > > Then I fixed l10n and tagged again, completely missing that
> > > > > "increase_frameworks_version.sh step2" was never done.
> > > > > >
> > > > > > Sigh, I wish svn.kde.org would work for the way we're using it
> at
> > > > > release time.
> > > > >
> > > > > One thing we may try is moving Frameworks to the "po injection"
> test
> > > group.
> > > > >
> > > > > "po injection" = scripty commits po files back to git
> > > > >
> > > > > Plasma Mobile Gear has been using it and as far as I understand it
> is
> > > > > working relatively well.
> > > > >
> > > > > Example:
> > > > > https://invent.kde.org/plasma-mobile/alligator/-/commits/master/po
> > > > >
> > > > > This way you can remove any special handling of l10n altogether
> from
> > > the
> > > > > KDE Frameworks r

Re: KDE Frameworks 5.94.0

[Ben Cooksley]

On Tue, May 17, 2022 at 10:10 AM Albert Astals Cid  wrote:

> El dilluns, 16 de maig de 2022, a les 11:50:13 (CEST), Ben Cooksley va
> escriure:
> > On Mon, May 16, 2022 at 9:39 AM Albert Astals Cid  wrote:
> >
> > > El diumenge, 15 de maig de 2022, a les 23:03:27 (CEST), David Faure va
> > > escriure:
> > > > On samedi 14 mai 2022 20:48:55 CEST Albert Astals Cid wrote:
> > > > > El diumenge, 8 de maig de 2022, a les 0:11:35 (CEST), David Faure
> va
> > > escriure:
> > > > > > On samedi 7 mai 2022 18:38:44 CEST Antonio Rojas wrote:
> > > > > > > El sábado, 7 de mayo de 2022 15:31:17 (CEST), David Faure
> escribió:
> > > > > > > > Dear packagers,
> > > > > > > >
> > > > > > > > KDE Frameworks 5.94.0 has been uploaded to the usual place.
> > > > > > > >
> > > > > > > > New frameworks: none this time.
> > > > > > >
> > > > > > > This should have been a reply to this mail of course
> > > > > > >
> > > > > > > >  tr tt ug uk and uz translations are missing from all
> tarballs.
> > > > > >
> > > > > > Thanks for noticing. My "update l10n" script did show an error
> about
> > > that
> > > > > > but I didn't see that error and moved on. I have now improved
> things
> > > so I
> > > > > > can't launch the next step if this step failed.
> > > > > >
> > > > > > I now uploaded new tarballs (also including
> > > > > > https://invent.kde.org/frameworks/
> > > plasma-framework/-/merge_requests/523)
> > > > > >
> > > > > > I hope it's all fine now, let me know otherwise.
> > > > >
> > > > > I've just realized that the packages dependencies have not been
> > > increased to
> > > > > 5.94 and they are just at 5.93. I guess that's not that bad, but
> just
> > > want
> > > > > to make sure that doesn't mean some other change may be also
> missing?
> > > >
> > > > Good catch. Fortunately nothing else should be missing. The reason
> this
> > > didn't happen is that I run
> > > >
> > > > cd ../src && ./kdesrc-build --src-only && cd ../release-tools &&
> > > ./list_frameworks.sh && ./update_l10n.sh &&
> > > ./increase_frameworks_version.sh step2
> > > >
> > > > and update_l10n failed because anonsvn threw me out in the middle of
> it.
> > > > I didn't notice, ran the next step (./make_rc_tag.sh) and this is
> how we
> > > got tags with missing languages.
> > > > Then I fixed l10n and tagged again, completely missing that
> > > "increase_frameworks_version.sh step2" was never done.
> > > >
> > > > Sigh, I wish svn.kde.org would work for the way we're using it at
> > > release time.
> > >
> > > One thing we may try is moving Frameworks to the "po injection" test
> group.
> > >
> > > "po injection" = scripty commits po files back to git
> > >
> > > Plasma Mobile Gear has been using it and as far as I understand it is
> > > working relatively well.
> > >
> > > Example:
> > > https://invent.kde.org/plasma-mobile/alligator/-/commits/master/po
> > >
> > > This way you can remove any special handling of l10n altogether from
> the
> > > KDE Frameworks release scripts
> > >
> >
> > Is there any particular reason why we can't rollout po injection to all
> > repositories?
>
> We need to adapt the release scripts not to fetch l10n, we also have
> various release scripts that inject ki18n_install/kdoctools_install when
> they do the fecth, so we need to properly add those calls to the root
> CMakeLists.txt


> Not a huge blocker, but it needs to be decided that we should do it and
> then do it.
>

Given the number of benefits it has to release managers (no more tooling
needed to download translations and integrate them), as well as build
processes for nightly builds and for builds on developer systems I think
we've a fairly compelling reason to switch it on globally. It will also
ensure good CI coverage of the CMake files which should stop issues around
ki18n_install macros which have happened a few times.

It'll also reduce the load on Leptone (the server for invent.kde.org and
svn.kde.org) at release time.

Cheers,
Ben


>
> Cheers,
>   Albert
>
> >
> >
> > >
> > > Cheers,
> > >   Albert
> > >
> >
> > Cheers,
> > Ben
> >
> >
> > >
> > > >
> > > > I have now added more error checking, including at the beginning of
> > > make_rc_tag.sh,
> > > > as well as a reminder to run "step2" after fixing the l10n problems.
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> >
>
>
>
>
>

Re: KDE Frameworks 5.94.0

[Ben Cooksley]

On Mon, May 16, 2022 at 9:39 AM Albert Astals Cid  wrote:

> El diumenge, 15 de maig de 2022, a les 23:03:27 (CEST), David Faure va
> escriure:
> > On samedi 14 mai 2022 20:48:55 CEST Albert Astals Cid wrote:
> > > El diumenge, 8 de maig de 2022, a les 0:11:35 (CEST), David Faure va
> escriure:
> > > > On samedi 7 mai 2022 18:38:44 CEST Antonio Rojas wrote:
> > > > > El sábado, 7 de mayo de 2022 15:31:17 (CEST), David Faure escribió:
> > > > > > Dear packagers,
> > > > > >
> > > > > > KDE Frameworks 5.94.0 has been uploaded to the usual place.
> > > > > >
> > > > > > New frameworks: none this time.
> > > > >
> > > > > This should have been a reply to this mail of course
> > > > >
> > > > > >  tr tt ug uk and uz translations are missing from all tarballs.
> > > >
> > > > Thanks for noticing. My "update l10n" script did show an error about
> that
> > > > but I didn't see that error and moved on. I have now improved things
> so I
> > > > can't launch the next step if this step failed.
> > > >
> > > > I now uploaded new tarballs (also including
> > > > https://invent.kde.org/frameworks/
> plasma-framework/-/merge_requests/523)
> > > >
> > > > I hope it's all fine now, let me know otherwise.
> > >
> > > I've just realized that the packages dependencies have not been
> increased to
> > > 5.94 and they are just at 5.93. I guess that's not that bad, but just
> want
> > > to make sure that doesn't mean some other change may be also missing?
> >
> > Good catch. Fortunately nothing else should be missing. The reason this
> didn't happen is that I run
> >
> > cd ../src && ./kdesrc-build --src-only && cd ../release-tools &&
> ./list_frameworks.sh && ./update_l10n.sh &&
> ./increase_frameworks_version.sh step2
> >
> > and update_l10n failed because anonsvn threw me out in the middle of it.
> > I didn't notice, ran the next step (./make_rc_tag.sh) and this is how we
> got tags with missing languages.
> > Then I fixed l10n and tagged again, completely missing that
> "increase_frameworks_version.sh step2" was never done.
> >
> > Sigh, I wish svn.kde.org would work for the way we're using it at
> release time.
>
> One thing we may try is moving Frameworks to the "po injection" test group.
>
> "po injection" = scripty commits po files back to git
>
> Plasma Mobile Gear has been using it and as far as I understand it is
> working relatively well.
>
> Example:
> https://invent.kde.org/plasma-mobile/alligator/-/commits/master/po
>
> This way you can remove any special handling of l10n altogether from the
> KDE Frameworks release scripts
>

Is there any particular reason why we can't rollout po injection to all
repositories?


>
> Cheers,
>   Albert
>

Cheers,
Ben


>
> >
> > I have now added more error checking, including at the beginning of
> make_rc_tag.sh,
> > as well as a reminder to run "step2" after fixing the l10n problems.
> >
> >
>
>
>
>
>

Re: plasma 5.24 tars ready for packaging

[Ben Cooksley]

On Tue, Feb 8, 2022 at 1:12 AM Jonathan Riddell  wrote:

> I'm not going to publish updates that just remove an important feature.
> Rather there needs to be discussion in the normal KDE method and that
> feature should be fixed.
>

Sorry but i'm going to categorically reject in the strongest possible terms
the above statement.

What you are in essence saying is that your view is that it is acceptable
to conduct a distributed denial of service attack on someone (even if it
unintentional) and then refuse to disable the functionality in question
while the issue is investigated in full and fixed properly.
That quite simply is appalling.


> Jonathan
>

Regards,
Ben


>
>
> On Sun, 6 Feb 2022 at 18:46, Ben Cooksley  wrote:
>
>> On Fri, Feb 4, 2022 at 7:52 AM Jonathan Riddell  wrote:
>>
>>> The tars for Plasma 5.24 are ready on deino for packaging in
>>> distributions.  Release is due next Tuesday.
>>>
>>
>> Hi Jonathan,
>>
>> I've now withdrawn these tarballs as they contain code that performs a
>> denial of service attack on KDE.org infrastructure.
>>
>> As this affects more than just Discover (with KWin, plasma-workspace and
>> kdeplasma-addons all containing defects that are part of this series as
>> well) a full respin of all packages will be required.
>>
>> We also need patch releases of Discover for all versions going back to
>> Plasma/5.18. While I appreciate that some of these are "out of support" the
>> extraordinary nature of the problem we are facing requires it to be made
>> (much like how Microsoft released a fix for Windows XP in the wake of
>> Wannacry)
>>
>>
>>>
>>> Jonathan
>>>
>>>
>> Thanks,
>> Ben
>>
>

Re: plasma 5.24 tars ready for packaging

[Ben Cooksley]

On Fri, Feb 4, 2022 at 7:52 AM Jonathan Riddell  wrote:

> The tars for Plasma 5.24 are ready on deino for packaging in
> distributions.  Release is due next Tuesday.
>

Hi Jonathan,

I've now withdrawn these tarballs as they contain code that performs a
denial of service attack on KDE.org infrastructure.

As this affects more than just Discover (with KWin, plasma-workspace and
kdeplasma-addons all containing defects that are part of this series as
well) a full respin of all packages will be required.

We also need patch releases of Discover for all versions going back to
Plasma/5.18. While I appreciate that some of these are "out of support" the
extraordinary nature of the problem we are facing requires it to be made
(much like how Microsoft released a fix for Windows XP in the wake of
Wannacry)


>
> Jonathan
>
>
Thanks,
Ben

Gitlab Bugzilla integration

[Ben Cooksley]

Hi all,

This afternoon work has been completed to better link Gitlab with Bugzilla,
allowing people to get from Gitlab more quickly to Bugzilla and also
enabling us to link CCBUG/BUG references in commits, issues and merge
requests from Gitlab over to Bugzilla.

This functionality can be seen in action on
https://invent.kde.org/graphics/digikam/-/commit/7ca7bf03b11ae72842006af8a66ed02894a4a605
(note that content posted prior to this being enabled may not feature links
due to caching in Gitlab)

This integration does not change in any way the use of Gitlab Issues, which
continue to remain intended for contributor collaboration and project
planning.

Use of this functionality requires the setup of some metadata within
sysadmin/repo-metadata which a number of projects have already completed.
Once added it will be synced to Gitlab overnight and will become available
the next day.

Thanks,
Ben Cooksley
KDE Sysadmin

Re: Fwd: [bugs.kde.org] [Bug 445822] New: KMail currently at 5.18.3, but the bug reporter only has options upto 5.16.3

[Ben Cooksley]

On Sun, Nov 21, 2021 at 7:57 AM Heiko Becker  wrote:

> Hello Ben,
>

Hi Heiko,


> On Saturday, 20 November 2021 19:19:37 CET, Ben Cooksley wrote:
> > Any ideas why the below would be taking place - aren't these supposed to
> be
> > added automatically?
>
> They are added automatically, but to the kmail product, not to kmail2.
>
> The wiki [1] mentions this mismatch problem and says to ask the release
> team mailing list. To be honest, I have no clear idea how to handle such
> cases. I guess we could introduce a mapping in the script. Are there any
> past examples?
>

To my knowledge, KMail is the only project/product that uses a Bugzilla
product name that is different from the repository name.
It is therefore the sole exception to that rule.

I'd suggest a mapping in the script as the best path forward here, yes -
unfortunately i'm not aware of any other examples/precedent of this being
done.


>
> Regards,
> Heiko
>

Cheers,
Ben


> [1] https://community.kde.org/Guidelines_and_HOWTOs/Application_Versioning
>
> > -- Forwarded message -
> > From: strangequark 
> > Date: Sun, Nov 21, 2021 at 5:29 AM
> > Subject: [bugs.kde.org] [Bug 445822] New: KMail currently at 5.18.3, but
> > the bug reporter only has options upto 5.16.3
> > To: 
> >
> >
> > https://bugs.kde.org/show_bug.cgi?id=445822
> >
> > Bug ID: 445822
> >Summary: KMail currently at 5.18.3, but the bug reporter only
> > has options upto 5.16.3
> >Product: bugs.kde.org
> >Version: unspecified
> >   Platform: unspecified
> > OS: Unspecified
> > Status: REPORTED
> >   Severity: normal
> >   Priority: NOR
> >  Component: general
> >   Assignee: sysad...@kde.org
> >   Reporter: random1123581...@protonmail.com
> > CC: she...@kde.org
>
>

Fwd: [bugs.kde.org] [Bug 445822] New: KMail currently at 5.18.3, but the bug reporter only has options upto 5.16.3

[Ben Cooksley]

Hi Release Team,

Any ideas why the below would be taking place - aren't these supposed to be
added automatically?

Cheers,
Ben

-- Forwarded message -
From: strangequark 
Date: Sun, Nov 21, 2021 at 5:29 AM
Subject: [bugs.kde.org] [Bug 445822] New: KMail currently at 5.18.3, but
the bug reporter only has options upto 5.16.3
To: 


https://bugs.kde.org/show_bug.cgi?id=445822

Bug ID: 445822
   Summary: KMail currently at 5.18.3, but the bug reporter only
has options upto 5.16.3
   Product: bugs.kde.org
   Version: unspecified
  Platform: unspecified
OS: Unspecified
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: sysad...@kde.org
  Reporter: random1123581...@protonmail.com
CC: she...@kde.org
  Target Milestone: ---

SUMMARY
The summary above

STEPS TO REPRODUCE
1. Try filing a bug in the KMail2 category

OBSERVED RESULT
There is no option to choose the current stable version 5.18.3

EXPECTED RESULT
It should be updated to show the latest releases.

SOFTWARE/OS VERSIONS
n/a

ADDITIONAL INFORMATION
none

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: Leak of Frameworks 5.88.0

[Ben Cooksley]

On Sun, Nov 14, 2021 at 9:42 AM Marc Deop i Argemí <
marcd...@fedoraproject.org> wrote:

> On Saturday, 13 November 2021 03:49:32 CET Ben Cooksley wrote:
> > Hi all,
>

Hi Marc,

>
> > It has recently been brought to my attention that packages of KDE
> > Frameworks 5.88.0 have been prematurely released by the distribution
> > PCLinuxOS, as visible at https://repology.org/project/krunner/versions
> >
>
> Maybe (hopefully) it was just a mistake?  We should contact them and ask.
> ( I
> acknowledge this seems like wishful thinking though).
>
> > they obtained the packages from someone else (either because they
> directly
> > shared their access, because they shared the packages with PCLinuxOS or
> > because PCLinuxOS has discovered the location of source packages for one
> or
> > more distributions).
>
> As Neal mentioned in another email, some distros already have the packages
> prepared and they are publicly available (Fedora, Maegia and possibly
> others)
> although not in their stable releases.
>
> In particular, we (Fedora KDE-SIG) build the packages in Rawhide (the
> development version of Fedora) and we use a COPR( like an Ubuntu PPA)
> under my
> namespace to build packages for early adopters who help us find issues.
>
> Unfortunately, if somebody wants to gather the sources from those places
> they
> certainly can do so without real blockers.
>
> If it's a problem, we can stop building in COPR until the release is
> official. I
> asked a few months ago and I was told it was ok to have it as long as it
> was
> not publicly announced ( I don't remember who told me though, apologies).
>

That may have been me :)


> The big problem here is: not building in Rawhide would complicate
> preparing
> packages quite a bit for us. We could probably find a solution, of course,
> but
> I rather not change the existing mechanism for practical reasons.
>

As long as the COPR repository in question is not widely advertised I think
what you're doing is perfectly fine.
>From my understanding your repository is only shared among members of your
team and it isn't marked as official so nobody else should be aware of it.


>
> > It would be appreciated if distributions could please review whether it
> is
> > possible that PCLinuxOS obtained the packages via them and ask the
> > PCLinuxOS team to please contact us as it would be preferrable that such
> > premature leaks/releases did not take place.
> >
>
> I will make sure to bring this up on our (Fedora KDE-SIG) next meeting on
> Monday to talk about it. Any KDE person is more than welcome to join
> (Nate,
> Carl, Aleix join us somehow often :-) )
>

Thanks.

One possibility is that distributions could periodically change the
location where they "stage" the packages before release (by renaming the
repository, creating a new one, etc) to ensure that only those who should
be aware of the correct URL to the repository have it to hand.

Cheers,
Ben

Re: Leak of Frameworks 5.88.0

[Ben Cooksley]

On Sun, Nov 14, 2021 at 12:11 AM Nicolas Lécureuil 
wrote:

> Le 2021-11-13 04:15, Neal Gompa a écrit :
> > On Fri, Nov 12, 2021 at 9:49 PM Ben Cooksley  wrote:
> >>
> >> Hi all,
> >>
> >> It has recently been brought to my attention that packages of KDE
> >> Frameworks 5.88.0 have been prematurely released by the distribution
> >> PCLinuxOS, as visible at https://repology.org/project/krunner/versions
> >>
> >> This is somewhat concerning for several reasons, but in particular
> >> because they don't have an early access packager account of their own
> >> - meaning they obtained the packages from someone else (either because
> >> they directly shared their access, because they shared the packages
> >> with PCLinuxOS or because PCLinuxOS has discovered the location of
> >> source packages for one or more distributions).
> >>
> >> This is now the second time in as many months that packages have been
> >> made available earlier than they should have by one or more
> >> distributions.
> >>
> >> While this isn't a substantial problem, it is of concern as the
> >> purpose of the pre-release mechanism is to allow any final issues to
> >> be ironed out before the final release is announced and made publicly
> >> available - which this premature release is defeating.
> >>
> >> It would be appreciated if distributions could please review whether
> >> it is possible that PCLinuxOS obtained the packages via them and ask
> >> the PCLinuxOS team to please contact us as it would be preferrable
> >> that such premature leaks/releases did not take place.
> >>
> >
> > I would be very shocked if PCLinuxOS interacts with the KDE community
> > at all. My understanding is that they're quite insular and they grab
> > package sources from other distros for their builds.
> >
> > At least right now, Fedora Rawhide and Mageia Cauldron have KF5 5.88
> > committed and built. Chances are pretty good that they got it from
> > there. Fedora committed it 3 days ago. Mageia did it 4 days ago.
> >
> > If you want them to hold back, you'll have to reach out to PCLinuxOS
> > yourself.
>
> Hi,
>

HI Nicolas,


> i don't know if this is us or not but in any case we will be more
> careful on when we release.
>

Your publication of the release has been fine - about the only thing I
might suggest is periodically changing the location of your staging/test
repository which contains the packages to break any automation people like
the folks at PCLinuxOS have if they are harvesting the packages from you.


> When we receive the mail about new release can we have the real "embargo
> date" ?
>
> --
> Regards,
> Nicolas Lécureuil
> Mageia KDE Team
>

Cheers,
Ben

Leak of Frameworks 5.88.0

[Ben Cooksley]

Hi all,

It has recently been brought to my attention that packages of KDE
Frameworks 5.88.0 have been prematurely released by the distribution
PCLinuxOS, as visible at https://repology.org/project/krunner/versions

This is somewhat concerning for several reasons, but in particular because
they don't have an early access packager account of their own - meaning
they obtained the packages from someone else (either because they directly
shared their access, because they shared the packages with PCLinuxOS or
because PCLinuxOS has discovered the location of source packages for one or
more distributions).

This is now the second time in as many months that packages have been made
available earlier than they should have by one or more distributions.

While this isn't a substantial problem, it is of concern as the purpose of
the pre-release mechanism is to allow any final issues to be ironed out
before the final release is announced and made publicly available - which
this premature release is defeating.

It would be appreciated if distributions could please review whether it is
possible that PCLinuxOS obtained the packages via them and ask the
PCLinuxOS team to please contact us as it would be preferrable that such
premature leaks/releases did not take place.

Thanks,
Ben Cooksley
KDE Sysadmin

Re: KDE Frameworks 5.87.0

[Ben Cooksley]

On Thu, Oct 14, 2021 at 9:27 AM Luca Beltrame  wrote:

> In data mercoledì 13 ottobre 2021 19:24:48 CEST, Ben Cooksley ha scritto:
>
> > It would appear that the necessary dependencies between targets aren't
> set
> > up properly?
>
> They aren't - one of the reasons I had a hard time packaging the bindings
> for
> openSUSE.
>

Sad to hear this - that might explain why I vaguely recall us adding the
necessary SIP packages at one point to build these bindings.
The unreliability introduced by their presence would have likely led me to
remove them as we would need the builds to be reliable.

Any interest from those who use these bindings to fix the CMake
dependencies here?
Otherwise i'll need to remove the SIP packages as the need for reliable
builds outweighs the value provided from having them present (i'd suggest
we disable them from building by default even)

Cheers,
Ben


> --
> Luca Beltrame - KDE Forums team
> GPG key ID: A29D259B

Re: KDE Frameworks 5.87.0

[Ben Cooksley]

On Tue, Oct 5, 2021 at 8:46 PM Ben Cooksley  wrote:

> On Mon, Oct 4, 2021 at 9:28 PM Antonio Rojas  wrote:
>
>> El lunes, 4 de octubre de 2021 10:10:02 (CEST), Ben Cooksley escribió:
>>
>> > If someone could confirm the SIP version we need that would be awesome.
>> >
>> > Cheers,
>> > Ben
>> >
>>
>> Yes, KF5 doesn't support anything newer than sip 4.
>>
>
> Thanks for confirming - i've now introduced this to our Linux image.
>
> https://invent.kde.org/sysadmin/ci-tooling/commit/7c9b1c2aa28536a9f99c165abbfccc347257f468
>

I now remember why we removed those packages - because it made our builds
unreliable.
Please see https://invent.kde.org/sysadmin/ci-management/-/jobs/141503

It would appear that the necessary dependencies between targets aren't set
up properly?


> Cheers,
> Ben
>

Thanks,
Ben

Re: KDE Frameworks 5.87.0

[Ben Cooksley]

On Mon, Oct 4, 2021 at 9:28 PM Antonio Rojas  wrote:

> El lunes, 4 de octubre de 2021 10:10:02 (CEST), Ben Cooksley escribió:
>
> > If someone could confirm the SIP version we need that would be awesome.
> >
> > Cheers,
> > Ben
> >
>
> Yes, KF5 doesn't support anything newer than sip 4.
>

Thanks for confirming - i've now introduced this to our Linux image.
https://invent.kde.org/sysadmin/ci-tooling/commit/7c9b1c2aa28536a9f99c165abbfccc347257f468

Cheers,
Ben

Re: KDE Frameworks 5.87.0

[Ben Cooksley]

On Mon, Oct 4, 2021 at 4:44 AM Luca Beltrame  wrote:

> In data domenica 3 ottobre 2021 10:44:29 CEST, Ben Cooksley ha scritto:
>
> Hello Ben,
>
> > Does anyone know which SUSE packages are required for the bindings to be
> > built?
>
> I think python38-qt5-sip, python38-qt5-devel, python3-sip4, python38-qt5
> and
> python38-sip4-devel  would be necessary for the build system to pick it
> up.
> But I completely forgot which sip version corresponds to which Qt version.
> It
> should be sip version 4, but feel free to correct me.
>

Thanks for those details - i'll see about introducing that into our images
in the next few days.

If someone could confirm the SIP version we need that would be awesome.

Cheers,
Ben


> --
> Luca Beltrame - KDE Forums team
> GPG key ID: A29D259B

Re: KDE Frameworks 5.87.0

[Ben Cooksley]

On Sun, Oct 3, 2021 at 9:35 PM David Faure  wrote:

> On samedi 2 octobre 2021 21:08:06 CEST Antonio Rojas wrote:
> > El sábado, 2 de octubre de 2021 20:10:54 (CEST), David Faure escribió:
> > > Dear packagers,
> > >
> > > KDE Frameworks 5.87.0 has been uploaded to the usual place.
> >
> > Hi,
> >  kcoreaddons python bindings broke again. Fixed in
> > https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/139
>
> I really wish the CI would enable python bindings so we can catch this
> earlier.
> I can't remember if we discussed that in the past (I assume so...) -
> CC'ing sysadmin@.
>
> Here are the respins (kcoreaddons for python, kwidgetsaddons for the fix
> for
>  https://bugs.kde.org/show_bug.cgi?id=442332)
>

I'm not sure if we did take a look into this previously, or if we did
enable it and found it broke quite a bit of stuff...

Does anyone know which SUSE packages are required for the bindings to be
built?


> kcoreaddons v5.87.0-rc2
> e69eb4abf53b6e65c8eecfc59016aed50064b3f7
> d29fe93b58fec0edb3387d5bf5290366e64a5975df44c1b062cc4e29cfbfeda6
> sources/kcoreaddons-5.87.0.tar.xz
>
> kwidgetsaddons v5.87.0-rc2
> dae908efa02453d38693ff2f3ff13a93eb7442e2
> 2b119b3f886131009d24e139a313fb27c2ed3f681534d9297ade40153b4dfb01
> sources/kwidgetsaddons-5.87.0.tar.xz
>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
>
>
>
Cheers,
Ben

Re: Frameworks releases timing

[Ben Cooksley]

On Fri, Sep 10, 2021 at 10:22 AM Heiko Becker  wrote:

> On Thursday, 9 September 2021 10:10:29 CEST, Ben Cooksley wrote:
> > On Thu, Sep 9, 2021 at 9:54 AM Adriaan de Groot  wrote:
> > - is there a polite tap-on-the-shoulder kind of message to send to
> distro's
> >> if
> >> the answer is "no", to remind them not to push out packages before the
> >> dust
> >> settles? (e.g. for respins )
> >>
> >
> > If memory serves, the agreement for pre-release tarballs is that
> > distributions may package and test them internally, but they're not to
> make
> > them available to general users.
>
> I would assume they are available to general users, if they are visible to
> repology.
>
> This also isn't limited to Frameworks, I ususally also see new KDE Gear
> releases in repology before the actual release date (and I think a few
> times even a +a for respins).
>

I've checked with both distributions and in both cases they were
unintentional due to accidental publishing, or to Repology finding a
private repository.
The distributions in question have now corrected both of those.


> Regards,
> Heiko
>

Cheers,
Ben

Re: Frameworks releases timing

[Ben Cooksley]

On Thu, Sep 9, 2021 at 9:54 AM Adriaan de Groot  wrote:

> Frameworks 5.86 haven't been released yet; from the calendar it looks like
> that will happen next week. However, there's a couple of Linux distro's
> that
> have packages up already. This makes the repology.org feed for frameworks
> a
> little weird -- 5.86.0 is "green" because it's latest, because it's
> available
> from two (?) distro's, but it's not officially released.
>
> Nearly everyone is red, because they ship the released 5.85.0.
>
> Regular people who might want to build-from-source (released tarballs, not
> git) can't even get the 5.86 tarballs yet.
>
> I happen to have access to the FreeBSD packaging "stage" tree, so I can
> see
> that Tobias -- who has access to that tree, and **also** access to the pre-
> release tarballs -- has prepared the packages for the release, but not
> pushed
> the button to move it from staging to the real tree. Pushing that button
> would
> break source builds for me, a regular(-ish) user, because I can't fetch
> the
> pre-release tarballs.
>
> Anyway, long-story short:
> - should distro's be packaging up pre-release tarballs?
>

That is the intention of providing the pre-release tarballs, yes.

- is there a polite tap-on-the-shoulder kind of message to send to distro's
> if
> the answer is "no", to remind them not to push out packages before the
> dust
> settles? (e.g. for respins )
>

If memory serves, the agreement for pre-release tarballs is that
distributions may package and test them internally, but they're not to make
them available to general users.
Where possible this should be achieved by protecting access to the
repository/archives, however if distribution systems don't allow for that
then they are supposed to make use of a location that is not advertised and
only share the details of that location with people in their own teams.


>
> [ade]


Cheers,
Ben

Re: Gitlab CI - Inbound

[Ben Cooksley]

On Tue, Sep 7, 2021 at 9:09 PM David Edmundson 
wrote:

> Excellent news!! Thanks very much
>
> > Once the scripts have been proven successfully for Frameworks, we will
> look at extending them to projects that depend only on Frameworks and
> repositories
>
> Does this mean we would like Plasma to wait a while before merging?
> Is it worth us creating the kde-cli files and not merging them so we
> have some test cases ready?
>

You can certainly get the .kde-ci.yml files in position - I do not expect
the format of them to change at this stage.

The big thing that will delay the rollout is determining how best to handle
the situation of when two projects want different versions of the same
dependency.
I'm going to have to figure that out sooner than anticipated in any event
due to Phonon and plasma-wayland-protocols which are both dependencies of
Frameworks (yet which both also require Frameworks).


> David
>

Cheers,
Ben

Re: Gitlab CI - Inbound

[Ben Cooksley]

On Tue, Sep 7, 2021 at 6:20 AM Johnny Jazeix  wrote:

> Hi Ben,
> not sure on which priority it is regarding the KDE Frameworks but I've
> added one on GCompris (
> https://invent.kde.org/education/gcompris/-/commit/67c9839d7970b360b5d6b0ec928b492f9003d07d)
> if it can help on more tests.
>

Thanks for getting that landed Johnny.

Please note that you've specified no dependencies, so your builds won't
even have ECM available so you may wish to fix that.


> Cheers,
>
> Johnny
>

Cheers,
Ben


> Le dim. 5 sept. 2021 à 12:11, Ben Cooksley  a écrit :
>
>> On Sun, Sep 5, 2021 at 6:13 PM Ben Cooksley  wrote:
>>
>>> Hi all,
>>>
>>
>> Hi all,
>>
>>
>>> This morning after much work i'm happy to announce that the new
>>> generation CI scripts intended for use with Gitlab CI successfully
>>> completed their first build (of ECM, and then subsequently of KCoreAddons).
>>>
>>> This begins our first steps towards transferring CI over from Jenkins to
>>> Gitlab.
>>>
>>> These scripts are 'Gitlab native' and are designed to work in an
>>> environment where they will be running on merge requests, tags as well as
>>> all branches of our repositories - something the existing scripts were
>>> completely incompatible with. While there are still some infrastructural
>>> elements to put in place (such as 'seed jobs' to mass rebuild all projects
>>> after substantial changes and 'cleanup jobs' to remove old builds from the
>>> Package Registry) the core elements needed for initial testing of these
>>> scripts are now ready.
>>>
>>
>> As an update, an initial version of the seed job tooling is now ready,
>> however testing that tooling requires that dependency information be
>> available.
>> This requires that the .kde-ci.yml files be populated in repositories.
>>
>> It would be appreciated if people could please work on getting these
>> files populated in Frameworks (as everyone needs those) as well as in their
>> own repositories as they are required before we can proceed much further.
>>
>>
>>> For those curious, the results of those initials runs can be found at
>>> https://invent.kde.org/groups/teams/ci-artifacts/-/packages
>>>
>>> Due to the challenges associated with having to handle all of the
>>> different forms of build and the versioning of this information, these
>>> scripts also represent a radical change in how CI builds will be conducted
>>> - with a large part of the configuration of the jobs themselves, including
>>> information on project dependencies now shifting to files located within
>>> the repository themselves. Those who monitor commits to Frameworks
>>> repositories will have noticed the appearance of these '.kde-ci.yml' files
>>> in some repositories.
>>>
>>> To assist in the future rollout of the CI system it would be appreciated
>>> if projects could please begin setting up these files within their
>>> respective repositories.
>>> You can find a template detailing the available options at
>>> https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config-template.yml
>>>
>>> Where possible please avoid overriding the system defaults except where
>>> needed by your project (ie. don't just copy the template in full)
>>> The defaults mirror the template and can be found at
>>> https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config/global.yml
>>>
>>> In terms of the format of the 'Dependencies' section, please bear in
>>> mind the following:
>>> - For the 'on' section, the special value '@all' can be used to mean
>>> "All platforms" to avoid needing to update the file in the event additional
>>> platforms are added in the future
>>> - For the 'require' section:
>>>   1) Please only include the projects you *explicitly* depend on.
>>> Dependencies of your dependencies will be included automatically
>>>   2) When specifying a project, you must use the repository path on
>>> Gitlab. Legacy project paths (such as kde/workspace/plasma-desktop) are no
>>> longer in use and will not work.
>>>   3) There are three special values for the branch name - '@same',
>>> '@latest' and '@stable' which can be used to refer to the branch/tag of a
>>> dependency.
>>>   '@same' means the branch name should be the same as that of the
>>> project being built and should be used when declaring dependencies among
>>&g

Re: Gitlab CI - Inbound

[Ben Cooksley]

On Tue, Sep 7, 2021 at 1:04 AM Tom Zander  wrote:

> On maandag 6 september 2021 11:48:39 CEST Ben Cooksley wrote:
> > > Pushing everything into required is likely not scalable,
> > > causing projects too wait too long for compile.
> > > Avoiding the optional ones means you lack coverage of compile
> > > and testing failures due to changes in libs.
> >
> > The CI system has reused the results of previous builds of
> > dependencies since the very first generation of the system
>
> We seem to be talking about two slightly different topics.
>
> When the (for instance) KIO repo changes, then the CI will
> obviously rebuild that repo and will pull in all the things that
> kio depends on.
>
> What many CIs do is additionally trigger rebuilds of projects
> that _use_ KIO, by them marking kio as a required dependency.
>

Our CI system has never done this, in part due to difficulties in
communicating this to Jenkins and also because of the build storm it would
create (which I believe is what you are referring to).
If we were to limit it to select projects, then we would need to 'pick'
those projects which would raise questions of favouritism which I'd rather
avoid.


> Imagine a small extragear app that uses some KIO stuff and it has
> some unit tests that would break as a result of the KIO change.
> When the KDE CI triggers a rebuild of projects that mark KIO as a
> required dependency, this little app would show its breaking as a
> result of the KIO push. Helping the KIO dev to realize the
> fallout as well.
> Without such a feature the app would show breakage at a random
> time in the future after a new push was made in that repo. Losing
> lots of dev time and compromising quality.
>
> Now, the optional requirements would help diminish the effect of
> changes in frameworks paralysing the build system by limiting the
> apps that gets scheduled for a rebuild.
>

> This kind of functionality becomes pretty easy to add to gen5.1
> of the CI, provided that at this time the dependencies are
> already split since doing it later is going to be an uphill
> battle.
>

Cheers,
Ben

Re: Gitlab CI - Inbound

[Ben Cooksley]

On Mon, Sep 6, 2021 at 9:00 PM Tom Zander  wrote:

> On zondag 5 september 2021 08:13:09 CEST Ben Cooksley wrote:
> > In terms of the format of the 'Dependencies' section,
>
> Playing with kde-build script and noticing the fast growing
> dependency trees we have today, I think it may be beneficial to
> have two types of compile dependencies in this setup.
>
> 1. required-to-build.
>   Which means that if something in the parent tree changes, this
>   one is scheduled for re-build.
>
> 2. optional. Equivalent of the cmake feature, if its not there
>   some code is not compiled.
>   At least once before a release the full dependencies can be
>   compiled to see if it fully compiles.
>

>From the perspective of the CI system there is basically no difference in
terms of making a dependency available or not as all dependencies are
always satisfied using previously built binaries.
If a dependency is not available your build fails.

We also have to make a hard choice - we either bring in optional
dependencies or we don't.

If we were to randomise whether we brought them in - or just brought them
in at certain times - then we would make the system state deterministic.
This could in some cases cause builds to break if it was random whether or
not we included optional dependencies. This would occur if the dependency
of a dependency of a project were rebuilt without an optional dependency
being present which in turn caused it's API interface to change. That would
then cause the project to fail as the dependency would now be broken.


>
> Pushing everything into required is likely not scalable, causing
> projects too wait too long for compile.
> Avoiding the optional ones means you lack coverage of compile and
> testing failures due to changes in libs.
>

The CI system has reused the results of previous builds of dependencies
since the very first generation of the system (this would be generation 5)
so this is not a problem facing the CI system.
For individual developers, my understanding is that kdesrc-build makes use
of incremental builds which eliminates most of the issue as well.


> What do people think, is it useful to have an 'optional' category
> in future there?
> Maybe useful to think that far ahead now people are populating
> their dependencies :-)
>
>
>
>
Thanks,
Ben

Re: Gitlab CI - Inbound

[Ben Cooksley]

On Mon, Sep 6, 2021 at 12:46 AM Nicolas Fella  wrote:

> On 05.09.21 08:13, Ben Cooksley wrote:
> > Hi all,
> >
> > This morning after much work i'm happy to announce that the new
> > generation CI scripts intended for use with Gitlab CI successfully
> > completed their first build (of ECM, and then subsequently of
> > KCoreAddons).
> >
> > This begins our first steps towards transferring CI over from Jenkins
> > to Gitlab.
> >
> > These scripts are 'Gitlab native' and are designed to work in an
> > environment where they will be running on merge requests, tags as well
> > as all branches of our repositories - something the existing scripts
> > were completely incompatible with. While there are still some
> > infrastructural elements to put in place (such as 'seed jobs' to mass
> > rebuild all projects after substantial changes and 'cleanup jobs' to
> > remove old builds from the Package Registry) the core elements needed
> > for initial testing of these scripts are now ready.
> >
> > For those curious, the results of those initials runs can be found at
> > https://invent.kde.org/groups/teams/ci-artifacts/-/packages
> > <https://invent.kde.org/groups/teams/ci-artifacts/-/packages>
> >
> > Due to the challenges associated with having to handle all of the
> > different forms of build and the versioning of this information, these
> > scripts also represent a radical change in how CI builds will be
> > conducted - with a large part of the configuration of the jobs
> > themselves, including information on project dependencies now shifting
> > to files located within the repository themselves. Those who monitor
> > commits to Frameworks repositories will have noticed the appearance of
> > these '.kde-ci.yml' files in some repositories.
> >
> > To assist in the future rollout of the CI system it would be
> > appreciated if projects could please begin setting up these files
> > within their respective repositories.
> > You can find a template detailing the available options at
> >
> https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config-template.yml
> > <
> https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config-template.yml
> >
> >
> > Where possible please avoid overriding the system defaults except
> > where needed by your project (ie. don't just copy the template in full)
> > The defaults mirror the template and can be found at
> >
> https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config/global.yml
> > <
> https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config/global.yml
> >
> >
> > In terms of the format of the 'Dependencies' section, please bear in
> > mind the following:
> > - For the 'on' section, the special value '@all' can be used to mean
> > "All platforms" to avoid needing to update the file in the event
> > additional platforms are added in the future
> > - For the 'require' section:
> >   1) Please only include the projects you *explicitly* depend on.
> > Dependencies of your dependencies will be included automatically
> >   2) When specifying a project, you must use the repository path on
> > Gitlab. Legacy project paths (such as kde/workspace/plasma-desktop)
> > are no longer in use and will not work.
> >   3) There are three special values for the branch name - '@same',
> > '@latest' and '@stable' which can be used to refer to the branch/tag
> > of a dependency.
> >   '@same' means the branch name should be the same as that of the
> > project being built and should be used when declaring dependencies
> > among projects in a release group.
> >   '@latest' and '@stable' refer to the corresponding branches
> > defined in the branch-rules.yml file, which can be found in
> > sysadmin/repo-metadata
> >
> > As a general rule, unless you require the absolute latest version of
> > another project in another release unit, it is recommended that you
> > use @stable.
> > Please avoid using explicit branch names unless absolutely necessary.
> >
> > At this time it is expected that the first set of Gitlab CI builds
> > using the new scripts may be conducted for Frameworks within the next
> > week or so, assuming the build of the seed jobs goes according to plan.
> >
> > Once the scripts have been proven successfully for Frameworks, we will
> > look at extending them to projects that depend only on Frameworks and
> > repositories within their release unit and finally will extend

Re: Gitlab CI - Inbound

[Ben Cooksley]

On Mon, Sep 6, 2021 at 11:03 AM Michael Reeves  wrote:

> How do we get a visual on exactly which lines are covered by auto testing
> and which aren't?
>

Please see
https://docs.gitlab.com/ee/user/project/merge_requests/test_coverage_visualization.html
for more details on how this works on Merge Requests.
To my knowledge this isn't exposed outside of Merge Requests.

Cheers,
Ben

Re: Gitlab CI - Inbound

[Ben Cooksley]

On Sun, Sep 5, 2021 at 6:13 PM Ben Cooksley  wrote:

> Hi all,
>

Hi all,


> This morning after much work i'm happy to announce that the new generation
> CI scripts intended for use with Gitlab CI successfully completed their
> first build (of ECM, and then subsequently of KCoreAddons).
>
> This begins our first steps towards transferring CI over from Jenkins to
> Gitlab.
>
> These scripts are 'Gitlab native' and are designed to work in an
> environment where they will be running on merge requests, tags as well as
> all branches of our repositories - something the existing scripts were
> completely incompatible with. While there are still some infrastructural
> elements to put in place (such as 'seed jobs' to mass rebuild all projects
> after substantial changes and 'cleanup jobs' to remove old builds from the
> Package Registry) the core elements needed for initial testing of these
> scripts are now ready.
>

As an update, an initial version of the seed job tooling is now ready,
however testing that tooling requires that dependency information be
available.
This requires that the .kde-ci.yml files be populated in repositories.

It would be appreciated if people could please work on getting these files
populated in Frameworks (as everyone needs those) as well as in their own
repositories as they are required before we can proceed much further.


> For those curious, the results of those initials runs can be found at
> https://invent.kde.org/groups/teams/ci-artifacts/-/packages
>
> Due to the challenges associated with having to handle all of the
> different forms of build and the versioning of this information, these
> scripts also represent a radical change in how CI builds will be conducted
> - with a large part of the configuration of the jobs themselves, including
> information on project dependencies now shifting to files located within
> the repository themselves. Those who monitor commits to Frameworks
> repositories will have noticed the appearance of these '.kde-ci.yml' files
> in some repositories.
>
> To assist in the future rollout of the CI system it would be appreciated
> if projects could please begin setting up these files within their
> respective repositories.
> You can find a template detailing the available options at
> https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config-template.yml
>
> Where possible please avoid overriding the system defaults except where
> needed by your project (ie. don't just copy the template in full)
> The defaults mirror the template and can be found at
> https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config/global.yml
>
> In terms of the format of the 'Dependencies' section, please bear in mind
> the following:
> - For the 'on' section, the special value '@all' can be used to mean "All
> platforms" to avoid needing to update the file in the event additional
> platforms are added in the future
> - For the 'require' section:
>   1) Please only include the projects you *explicitly* depend on.
> Dependencies of your dependencies will be included automatically
>   2) When specifying a project, you must use the repository path on
> Gitlab. Legacy project paths (such as kde/workspace/plasma-desktop) are no
> longer in use and will not work.
>   3) There are three special values for the branch name - '@same',
> '@latest' and '@stable' which can be used to refer to the branch/tag of a
> dependency.
>   '@same' means the branch name should be the same as that of the
> project being built and should be used when declaring dependencies among
> projects in a release group.
>   '@latest' and '@stable' refer to the corresponding branches defined
> in the branch-rules.yml file, which can be found in sysadmin/repo-metadata
>
> As a general rule, unless you require the absolute latest version of
> another project in another release unit, it is recommended that you use
> @stable.
> Please avoid using explicit branch names unless absolutely necessary.
>
> At this time it is expected that the first set of Gitlab CI builds using
> the new scripts may be conducted for Frameworks within the next week or so,
> assuming the build of the seed jobs goes according to plan.
>
> Once the scripts have been proven successfully for Frameworks, we will
> look at extending them to projects that depend only on Frameworks and
> repositories within their release unit and finally will extend them to
> projects with more complex dependency requirements. It is expected that the
> switch will be flipped on the Frameworks builds sometime in the next week
> or two.
>
> Please let me know if you have any questions on the above.
>
> Thanks,
> Ben Cooksley
> KDE Sysadmin
>

Thanks,
Ben

Gitlab CI - Inbound

[Ben Cooksley]

Hi all,

This morning after much work i'm happy to announce that the new generation
CI scripts intended for use with Gitlab CI successfully completed their
first build (of ECM, and then subsequently of KCoreAddons).

This begins our first steps towards transferring CI over from Jenkins to
Gitlab.

These scripts are 'Gitlab native' and are designed to work in an
environment where they will be running on merge requests, tags as well as
all branches of our repositories - something the existing scripts were
completely incompatible with. While there are still some infrastructural
elements to put in place (such as 'seed jobs' to mass rebuild all projects
after substantial changes and 'cleanup jobs' to remove old builds from the
Package Registry) the core elements needed for initial testing of these
scripts are now ready.

For those curious, the results of those initials runs can be found at
https://invent.kde.org/groups/teams/ci-artifacts/-/packages

Due to the challenges associated with having to handle all of the different
forms of build and the versioning of this information, these scripts also
represent a radical change in how CI builds will be conducted - with a
large part of the configuration of the jobs themselves, including
information on project dependencies now shifting to files located within
the repository themselves. Those who monitor commits to Frameworks
repositories will have noticed the appearance of these '.kde-ci.yml' files
in some repositories.

To assist in the future rollout of the CI system it would be appreciated if
projects could please begin setting up these files within their respective
repositories.
You can find a template detailing the available options at
https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config-template.yml

Where possible please avoid overriding the system defaults except where
needed by your project (ie. don't just copy the template in full)
The defaults mirror the template and can be found at
https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config/global.yml

In terms of the format of the 'Dependencies' section, please bear in mind
the following:
- For the 'on' section, the special value '@all' can be used to mean "All
platforms" to avoid needing to update the file in the event additional
platforms are added in the future
- For the 'require' section:
  1) Please only include the projects you *explicitly* depend on.
Dependencies of your dependencies will be included automatically
  2) When specifying a project, you must use the repository path on Gitlab.
Legacy project paths (such as kde/workspace/plasma-desktop) are no longer
in use and will not work.
  3) There are three special values for the branch name - '@same',
'@latest' and '@stable' which can be used to refer to the branch/tag of a
dependency.
  '@same' means the branch name should be the same as that of the
project being built and should be used when declaring dependencies among
projects in a release group.
  '@latest' and '@stable' refer to the corresponding branches defined
in the branch-rules.yml file, which can be found in sysadmin/repo-metadata

As a general rule, unless you require the absolute latest version of
another project in another release unit, it is recommended that you use
@stable.
Please avoid using explicit branch names unless absolutely necessary.

At this time it is expected that the first set of Gitlab CI builds using
the new scripts may be conducted for Frameworks within the next week or so,
assuming the build of the seed jobs goes according to plan.

Once the scripts have been proven successfully for Frameworks, we will look
at extending them to projects that depend only on Frameworks and
repositories within their release unit and finally will extend them to
projects with more complex dependency requirements. It is expected that the
switch will be flipped on the Frameworks builds sometime in the next week
or two.

Please let me know if you have any questions on the above.

Thanks,
Ben Cooksley
KDE Sysadmin

Re: Appstream BoF notes

[Ben Cooksley]

On Thu, Jun 24, 2021 at 11:50 PM Jonathan Riddell  wrote:

>
> Appstream BoF notes
>  - metadata updater rewrite should be its own repo so as not to break uses
> of existing code
>

Is there a plan to list all existing users of the code and migrate them to
the new rewrite?


>  - the rewrite should get tests to prove it works
>  - much of this must be a solved problem, aren't appstream or other users
> creating scripts that do these features? ideally it would go upstream to
> appstream.
>- appstreamcli has news-to-appstream converter and appstream-util has
> similar, probably not very useful as we don't use news files
> *https://blog.tenstral.net/2020/03/maintain-release-info-easily-in-metainfo-files.html*
> 
>  - should changelogs be translateable?
> - possibly yes, shouldn't be super hard to support in scripty
>  - "Date in iso standard e.g 04-03-2022" is not ISO format
>  - Links to artifacts could be generated
>  - release time checks prior to publishing tars? ideally.
>  - checks done in neon at
> https://metadata.neon.kde.org/appstream/user_focal/html/focal/main/issues/index.html
>  Actions: carl to close MR, put it in own repo (with a nice sounding name)
> or release-tools repo or releaseme, update scripty to make changelogs
> translateable
>
>
Cheers,
Ben

Re: Can we get tags and tarballs for the KDE Qt patch collection

[Ben Cooksley]

On Tue, Jun 8, 2021 at 10:52 PM Neal Gompa  wrote:

> On Mon, Jun 7, 2021 at 4:52 PM Albert Astals Cid  wrote:
> >
> > El dilluns, 7 de juny de 2021, a les 20:46:25 (CEST), Nate Graham va
> escriure:
> > > Hello folks,
> > >
> > > The Fedora packagers were mentioning to me today that it would be a lot
> > > easier for them to ship Qt with our patch collection if we made tags
> and
> > > tarballs. Is this something we could look into doing?
> >
> > We explicitly do not want to make releases
> >   https://community.kde.org/Qt5PatchCollection#Will_there_be_releases.3F
> >
> > Making a release means having to use of a version number, and any
> version number we use will be wrong.
> >
> > Don't think this as a product, think of it as a central place where
> patches are collected.
> >
> > If they want a tarball because using git is a problem, they can always
> use
> https://invent.kde.org/qt/qt/qtbase/-/archive/kde/5.15/qtbase-kde-5.15.tar.bz2
> ?
> >
>
> You *already* are using version numbers and bumped it to 5.15.3:
>
> https://blog.neon.kde.org/2021/06/04/kde-neons-qt-is-now-built-from-kdes-git-branches/
>
> This is unreasonable if you're going to make us need fixes from there.
> I'd rather we didn't pretend this is something other than what it is:
> a community maintained uplift of Qt 5.15 while Plasma works to move to
> Qt 6.
>
> Also, that URL is unstable, you'd get different things each time you'd
> fetch from it based on the HEAD of that branch.
>

Gitlab offers stable URLs based on a specific hash if absolutely required,
see:
https://invent.kde.org/qt/qt/qtbase/-/archive/2a2f3cd61f59ccec0eecb09e4a8795d7322edfcb/qtbase-2a2f3cd61f59ccec0eecb09e4a8795d7322edfcb.tar.bz2

Please note however that my previous comment on no automated access still
applies.


>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
>

Cheers,
Ben

Re: Can we get tags and tarballs for the KDE Qt patch collection

[Ben Cooksley]

On Tue, Jun 8, 2021 at 8:52 AM Albert Astals Cid  wrote:

> El dilluns, 7 de juny de 2021, a les 20:46:25 (CEST), Nate Graham va
> escriure:
> > Hello folks,
> >
> > The Fedora packagers were mentioning to me today that it would be a lot
> > easier for them to ship Qt with our patch collection if we made tags and
> > tarballs. Is this something we could look into doing?
>
> We explicitly do not want to make releases
>   https://community.kde.org/Qt5PatchCollection#Will_there_be_releases.3F
>
> Making a release means having to use of a version number, and any version
> number we use will be wrong.
>
> Don't think this as a product, think of it as a central place where
> patches are collected.
>
> If they want a tarball because using git is a problem, they can always use
> https://invent.kde.org/qt/qt/qtbase/-/archive/kde/5.15/qtbase-kde-5.15.tar.bz2
> ?
>

Please note that automated services should not use the /archive/ endpoints
provided by Gitlab - they're for human use only.
The recommendation here would be for distributions to periodically manually
download snapshots (using the above endpoints if they wish) and then upload
those into their systems.


> Cheers,
>   Albert
>

Cheers,
Ben


>
> >
> > Nate
> >
>
>
>
>
>

Re: KDE Frameworks 5.81.0

[Ben Cooksley]

On Sat, Apr 10, 2021 at 6:29 AM Dawid Wrobel  wrote:

> On Apr 3, 2021, at 4:50 PM, David Faure  wrote:
>
>
> ### Breeze Icons
>
> * Added branches with leaves to Kmymoney icon
>
>
> David, we ended up having to revert that change for now:
>
> https://invent.kde.org/frameworks/breeze-icons/-/commit/f1d947ff3bffa7337a53d4c54a7f49a1d24a349b
>
> Given how this is an application icon, in order to avoid it getting into
> circulation, we’d like to ask for it to be reverted from 5.81 release, if
> possible.
>

Hi Dawid,

Mind providing a bit of background to this? Both the revert commit and this
email are lacking any detail on this.


> My sincere apologies for this belated request.
>
> —
> With Kind Regards,
> Dawid Wróbel
>
>
Cheers,
Ben

Re: KDE Frameworks 5.81.0

[Ben Cooksley]

On Tue, Apr 6, 2021 at 5:21 AM Rik Mills  wrote:

> On 05/04/2021 18:06, Christophe Giboudeaux wrote:
> > Hey,
> >
> > On Saturday, 3 April 2021 22:50:48 CEST David Faure wrote:
> >> Dear packagers,
> >>
> >> KDE Frameworks 5.81.0 has been uploaded to the usual place.
> >>
> >> New frameworks: none this time.
> >>
> >> Public release next Saturday.
> >>
> >> Thanks for the packaging work!
> >
> > kwayland fails to build:
> >
> > [   55s] /home/abuild/rpmbuild/BUILD/kwayland-5.81.0/src/client/
> > plasmawindowmanagement.cpp:425:1: error: too many initializers for
> > 'org_kde_plasma_window_listener'
>
> That is because the changes in 5.81.0 requires plasma-wayland-protocols
> >= 1.2.0, and you are presumably trying to build it against v1.1
>
> Build the plasma-wayland-protocols 1.2.0 tar first, and it should work.
>
> There was a discussion about this earlier on #plasma on freenode
>
> In short, kwayland 5.81.0 needs to cmake depend on
> plasma-wayland-protocols >= 1.2.0
> At the moment that is not possible, as in an accompanying omission,
> plasma-wayland-protocols 1.2.0 tar declares itself in cmake as 1.1. So
> we are needing a respun plasma-wayland-protocols tar to fix its project
> version, then once that is done, a respun kwayland that can correctly
> depend on it.
>

I just processed a ticket for the release
of plasma-wayland-protocols-v1.2.1.tar.xz which I imagine will contain that
fix.


>
> Rik
>

Cheers,
Ben

Re: KDE release 20.12.0 packages available for packagers

[Ben Cooksley]

On Fri, 25 Dec 2020, 4:18 am Christoph Feck,  wrote:

> On 12/10/20 16:30, Heiko Becker wrote:
> > On Donnerstag, 10. Dezember 2020 15:32:35 CET, Christoph Feck wrote:
> >> While the 20.12.0 releases are now published, the KDE release team
> >> is still looking for volunteers to package future releases.
> >
> > considering that I've enjoyed nice tarballs as a packager for quite a
> > few years, I'd be willing to step up and give something back. I know my
> > way around a command line and git and I think I roughly know how the
> > release service tarballs are made.
>
> Hello Heiko,
>

Hi all,


> sorry for getting back to you this late. Thank you for volunteering to
> help the release team with future KDE releases! To get you started, I
> plan to involve you in the release process for the 20.12.1 releases.
>
> The steps involved are documented at https://phabricator.kde.org/T12272
> (but may a bit outdated). The schedule[1] says we should prepare the
> repositories before Jan 4. In the meantime, you could start preparing
> your system. I currently do not have access to the machine from where I
> do the releases, so some details might be missing.
>
> * git checkout the following repositories:
>  - sysadmin/release-tools (releases/20.12 branch)
>  - Jonathan Riddel's repository for "add_appstream_versions.sh"
>(which needs some Python setup)
>  - all repositories listed at release-tools/modules.git to a flat
>directory
>(there used to be a mapping file to find the invent location ...)
>

You can use the git-kclone script in repo-metadata to do this cloning - it
accepts both the repository identifiers (which are unique) or wildcard
rules to just clone larger numbers of repositories.

You will need a full clone of repo-metadata to use it though.


> * Locally adapt the config file in release-tools to point to the
>  add_appstream_versions location.
>
> * svn checkout the i18n data using release-tools/update_l10n.sh
>
> * ask sysadmins to get ssh access to these accounts:
>  - pkgapplicati...@capona.kde.org
>  - ftpad...@deino.kde.org
>  Also you need commit access to some repositories for WWW, but since
>  that recently changed, I am not sure about the repository names.
>

I believe the correct repository for this is websites/kde-org but Carl
should be able to confirm this.


> * make sure you have a GPG key setup. If you are not in our ring,
>  Albert knows best how to do the key signing via Internet video
>  conferencing (e.g. Jitsi).
>  If possible, also investigate how to get your key setup forwarded
>  to the capona account.
>
> (If anyone can correct me or add to this list, please do :)
>
> Merry Christmas and a Happy New Year to you and the whole KDE community!
>
> BG,
> Christoph
>

Many thanks,
Ben


> [1]
> https://community.kde.org/Schedules/release_service/20.12_Release_Schedule
>
> --
> Christoph Feck
> KDE Release Team
>
>

Re: Merge tags in master branch?

[Ben Cooksley]

On Sun, Nov 29, 2020 at 10:16 AM David Faure  wrote:

> On lundi 23 novembre 2020 16:11:02 CET Bhushan Shah wrote:
> > Hello,
> >
> > So I have one question regarding the how we do the framework versioning.
> > Namely the tags,
> >
> > So currently some packages have a versioned tags on their master branch,
> >
> > i.e
> >
> > karchive:
> >
> > ➜ git describe
> > v5.76.0-1-g7304c28
> >
> > While in case of some frameworks where translations needs to be taken
> > from svn, it is something super weird like,
> >
> > kdesu:
> >
> > ➜ git describe
> > v5.2.0-234-gb7ba89f
> >
> > Some packagers who package -git versions in their unstable repos check
> > the git describe to figure out what is current revision of the package
> > and having "wrong" version there bugs out weirdly.
>
> I know I'm doing something unusual with tags in KDE Frameworks
> (tags that are not part of a branch), but I'm surprised anyone would rely
> on
> `git describe` anyway, I've seen it being a bit unreliable/unexpected in
> the
> past (in non KDE repositories).
>
> > Do anyone have any opinion on "merging" latest git tag in master branch?
> > and potentially doing that for next releases as well?
>
> Merging the tag into master would work, I guess.
> One downside for KF5 developers is that the translated docbook files then
> have
> to be built. That's many screenfuls of things like
> [ 21%] Generating po/sr@latin/docs/kioslave5/webdav/index.cache.bz2
> which is just "noise" to developers, at least those who read the cmake
> output
> like I do ;-). And it might slow down compilation, I guess.
> You can check out v5.76.0 in kio to see what it looks like.
>
> Pushing translations every day as suggested by Harald creates the risk of
> a
> bad translation file breaking compilation. I remember catching that quite
> a
> few times when I started doing KF5 releases. But it hasn't happened for a
> long
> while so maybe there's now a git hook or something, to prevent that from
> happening?
>

Translations are still unfortunately located in SVN, and the hooks we have
for that have not changed in many, many years.
It's possible that scripty is performing some additional validation though
and correcting things there.

Cheers,
Ben


>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
>
>
>

Fwd: KDE Release Service 20.08.3 announcement broken on kde.org

[Ben Cooksley]

Forwarding to the appropriate mailing list for this

Cheers,
Ben

-- Forwarded message -
From: Andreas Sturmlechner 
Date: Thu, Nov 12, 2020 at 1:43 AM
Subject: KDE Release Service 20.08.3 announcement broken on kde.org
To: KDE release coordination 


These announcements continue to be problematic it seems. In the
'Announcements' part on kde.org front page, all it says is '20.08.3
Releases Source Info Page' which I doubt is the intended title, and
with no link to the actual release info page.

Regards,
Andreas

Re: Transition to new mirror infrastructure

[Ben Cooksley]

On Mon, Nov 9, 2020 at 11:02 PM Gilles Caulier 
wrote:

> Hi all,
>

Hi Gilles,


>
> Until milonia to deino transition stage, we can access to milonia with
> ssh to transfer weekly build of digiKam bundles, available at this
> url:
>
> https://files.kde.org/digikam/
>
> Now, we get this error message:
>
> [gilles@pc-gilles mxe]$ ssh digi...@deino.kde.org
> Welcome to Ubuntu 20.04.1 LTS (GNU/Linux 5.4.0-52-generic x86_64)
>
>  * Documentation:  https://help.ubuntu.com
>  * Management: https://landscape.canonical.com
>  * Support:https://ubuntu.com/advantage
> You do not have interactive login access to this machine.
> Contact the systems administrator for further assistance.
> Connection to deino.kde.org closed.
>
> On of the scripts to manage remote files (Windows bundles in this
> case) is this one :
>
>
> https://invent.kde.org/graphics/digikam/-/blob/master/project/bundles/mxe/04-build-installer.sh#L297
>
> As you can see, it use ssh, scp, and rsync.
>

You will need to port your scripts to use sftp in place of the existing
'ssh' commands present in that script.

Please note that you do not need to upload hashes manually (the .sum files
you currently upload).

These will be automatically generated for you by Mirrorbits - which detects
new files and generates them automatically (subject to approximately a five
minute delay as that is when it rescans the directory tree). The hashes it
generates will be served directly and securely to users (not guaranteed for
other files, where they may be redirected to a mirror instead)

Those hashes can be accessed at $fileUrl.sha256 or $fileUrl.sha1 for any
file on files.kde.org or download.kde.org.


>
> We have the same for MacOS, and Linux AppImage...
>
> Best regards
>
> Gilles Caulier
>

Regards,
Ben


>
> Le ven. 30 oct. 2020 à 09:56, Ben Cooksley  a écrit :
> >
> > Hi all,
> >
> > Just a heads up that over the weekend we're going to be migrating from
> the existing mirror master server (known as milonia.kde.org) to the new
> master server (which can be found under the name deino.kde.org).
> >
> > While this is not expected to have any impact on public access (as both
> systems will continue to serve download.kde.org and files.kde.org in the
> same form), it does mean that it may not be possible to upload new files
> for a short period of time.
> >
> > For those who are looking to upload files or perform releases over the
> weekend, it would be appreciated if you could please contact us so we can
> ensure that you are guided to the correct system.
> >
> > Thanks,
> > Ben Cooksley
> > KDE Sysadmin
>

Re: Transition to new mirror infrastructure

[Ben Cooksley]

On Wed, Nov 4, 2020 at 10:34 AM Rex Dieter  wrote:

> I'm stumped here why this isn't working as before on milonia, to
> transfer a whole bunch of files at a time with wildcards.
> While individual transfers are fine:
> rsync deino.kde.org:stable/release-service/20.08.3/src/yakuake-20.08.3.tar.xz
> . -v
> yakuake-20.08.3.tar.xz
> (success)
>
> Wildcards no longer work:
> rsync deino.kde.org:stable/release-service/20.08.3/src/*.xz .
> rsync: link_stat
> "/srv/archives/ftp/stable/release-service/20.08.3/src/*.xz" failed: No such
> file or directory (2)
> rsync error: some files/attrs were not transferred (see previous errors)
> (code 23) at main.c(1816) [Receiver=3.2.3]
> rsync: [Receiver] write error: Broken pipe (32)
>

Hi Rex,

As noted in my email to distributions@ yesterday, wildcards in this form
are not functionality natively supported by RSync.
This worked because bash was interpreting the regexes/wildcards for you.

The correct behaviour here would be to use the --include or --exclude
switches to rsync to obtain the desired behaviour.

Regards,
Ben


> Any ideas?
>
>
> On Sat, Oct 31, 2020 at 1:01 PM Ben Cooksley  wrote:
>
>> On Sun, Nov 1, 2020 at 4:49 AM Christoph Feck  wrote:
>>
>>> On 10/31/20 03:08, Ben Cooksley wrote:
>>> > This transition has now been completed, and going forward all access
>>> should
>>> > now be directed to deino.kde.org.
>>>
>>> Did I understand it correctly, that "deino" is the replacement for
>>> "milona", but shouldn't offer ssh/scp access anymore, but need to use
>>> sftp?
>>>
>>
>> Deino is the replacement to Milonia yes.
>> The restriction on access only applies to packagers and those with
>> accounts for managing data on
>> files.kde.org/cdn.kde.org/distribute.kde.org and doesn't apply to
>> ftpadmin.
>>
>>
>>> For what it's worth, I could successfully ssh login to
>>> ftpad...@deino.kde.org (using the credentials I used previously on
>>> milona), and could use mkdir/chmod in stable/release-service path,
>>> albeit response time was very laggy.
>>>
>>
>> I've investigated that issue with response times and found that the
>> network adapter was extremely unhappy and regularly resetting itself.
>> Following a system reboot it appears to have been corrected, however
>> we'll monitor the system to confirm this is the case.
>>
>>
>>> If that's not the correct replacement procedure, please clarify.
>>>
>>> BG,
>>> Christoph
>>>
>>
>> Many thanks,
>> Ben
>>
>>
>>>
>>> --
>>> Christoph Feck
>>> KDE Release Team
>>>
>>>

Re: Transition to new mirror infrastructure

[Ben Cooksley]

On Sun, Nov 1, 2020 at 4:49 AM Christoph Feck  wrote:

> On 10/31/20 03:08, Ben Cooksley wrote:
> > This transition has now been completed, and going forward all access
> should
> > now be directed to deino.kde.org.
>
> Did I understand it correctly, that "deino" is the replacement for
> "milona", but shouldn't offer ssh/scp access anymore, but need to use sftp?
>

Deino is the replacement to Milonia yes.
The restriction on access only applies to packagers and those with accounts
for managing data on files.kde.org/cdn.kde.org/distribute.kde.org and
doesn't apply to ftpadmin.


> For what it's worth, I could successfully ssh login to
> ftpad...@deino.kde.org (using the credentials I used previously on
> milona), and could use mkdir/chmod in stable/release-service path,
> albeit response time was very laggy.
>

I've investigated that issue with response times and found that the network
adapter was extremely unhappy and regularly resetting itself.
Following a system reboot it appears to have been corrected, however we'll
monitor the system to confirm this is the case.


> If that's not the correct replacement procedure, please clarify.
>
> BG,
> Christoph
>

Many thanks,
Ben


>
> --
> Christoph Feck
> KDE Release Team
>
>

Re: Transition to new mirror infrastructure

[Ben Cooksley]

On Fri, Oct 30, 2020 at 9:54 PM Ben Cooksley  wrote:

> Hi all,
>

Hi everyone,


>
> Just a heads up that over the weekend we're going to be migrating from the
> existing mirror master server (known as milonia.kde.org) to the new
> master server (which can be found under the name deino.kde.org).
>
> While this is not expected to have any impact on public access (as both
> systems will continue to serve download.kde.org and files.kde.org in the
> same form), it does mean that it may not be possible to upload new files
> for a short period of time.
>
> For those who are looking to upload files or perform releases over the
> weekend, it would be appreciated if you could please contact us so we can
> ensure that you are guided to the correct system.
>

This transition has now been completed, and going forward all access should
now be directed to deino.kde.org.

Those interested in the status of the mirror network, as well as estimates
on what the mirrors handle on our behalf can take a look at the mirror
statistics pages provided by our new mirror management system (Mirrorbits)
at https://files.kde.org/?mirrorstats and
https://download.kde.org/?mirrorstats


>
> Thanks,
> Ben Cooksley
> KDE Sysadmin
>

Cheers,
Ben

Transition to new mirror infrastructure

[Ben Cooksley]

Hi all,

Just a heads up that over the weekend we're going to be migrating from the
existing mirror master server (known as milonia.kde.org) to the new master
server (which can be found under the name deino.kde.org).

While this is not expected to have any impact on public access (as both
systems will continue to serve download.kde.org and files.kde.org in the
same form), it does mean that it may not be possible to upload new files
for a short period of time.

For those who are looking to upload files or perform releases over the
weekend, it would be appreciated if you could please contact us so we can
ensure that you are guided to the correct system.

Thanks,
Ben Cooksley
KDE Sysadmin

Re: RKWard 0.7.1 release candidate is available

[Ben Cooksley]

On Sun, Oct 11, 2020 at 10:30 PM Thomas Friedrichsmeier <
thomas.friedrichsme...@kdemail.net> wrote:

> Hi!
>

Hi Thomas,


>
> The RKWard 0.7.2 release is scheduled for October 16th. This mail is to
> inform you that a release candidate source package is available today.
> Barring any severe issues, this will be identical to the official
> release on Friday.
>
> This release brings a number of changes that packagers should be aware
> of:
>
> - RKWard now supports using QWebEngine instead of QtWebKit. QWebEngine
>   will automatically be used for compilation if available. Should you
>   wish to force using QtWebKit, pass -DNO_QT_WEBENGINE=1 to cmake.
> - RKWard can now load kate plugins (_not_ just ktexteditor plugins), and
>   these provide some rather important functionality. Thus the package
>   providing kate (or at least the kate plugins) should be made a
>   dependency, or a least of recommendation of RKWard.
> - In addition, kbibtex and pandoc will often by useful, and should at
>   least be suggested packages.
> - libintl is no longer a direct build dependency of RKWard.
>
> Release files:
> https://files.kde.org/rkward/testing/for_packaging/rkward-0.7.2.tar.gz
> SHA256
> :
> 452350a4057d9dc87bb7c7e2f5c38b5cb9715b42141186b0e8c4a28e3dd2adf6
>

Please note that projects are highly encouraged to make use of
download.kde.org when making releases such as this, rather than
files.kde.org (as download.kde.org is built for distributing releases,
while files.kde.org is built for distributing binary assets for use on end
user systems)


>
> Regards
> Thomas
>

Cheers,
Ben

Re: Add kio-gdrive to the release service

[Ben Cooksley]

On Wed, Jul 1, 2020 at 8:05 AM Albert Astals Cid  wrote:
>
> El dimarts, 30 de juny de 2020, a les 0:23:17 CEST, Elvis Angelaccio va 
> escriure:
> > On 29/06/20 23:41, Albert Astals Cid wrote:
> > > El dilluns, 29 de juny de 2020, a les 22:44:16 CEST, Elvis Angelaccio va 
> > > escriure:
> > >> On 24/06/20 00:25, Albert Astals Cid wrote:
> > >>> El dilluns, 22 de juny de 2020, a les 23:44:39 CEST, Elvis Angelaccio 
> > >>> va escriure:
> >  Hi release team,
> > 
> >  I'd like to add kio-gdrive to the release service. kio-gdrive depends 
> >  on
> >  libkgapi which is also included in the release service, so it makes
> >  sense to follow the same release schedule. It already happened once 
> >  that
> >  libkgapi changed the API and I could not make a new kio-gdrive release
> >  in time.
> > 
> >  Do you see any drawbacks? Please discuss :)
> > >>> You will lose the external versioning of the tarballs.
> > >> What do you mean exactly?
> > > I mean that kio-gdrive tarball released will be kio-gdrive-20.08.0.tar.xz 
> > > which as a followup of 1.3.0 may be weird.
> > >
> > > But if you think that's fine for your users, then no problem.
> >
> > Yes I think it would be fine.
> >
> > >
> > > You also need to decide if you want to internally align to 
> > > RELEASE_SERVICE_VERSION or keep your 1.x.y naming. If you keep to your 
> > > 1.x.y naming you need to commit to update it timely.
> >
> > Yes I'd prefer to switch to the automatic version bump provided by
> > RELEASE_SERVICE_VERSION. Otherwise I'll forget for sure :P
>
> Ok, since noone else seemed to complain i've added it to the list of modules 
> to be released
>
> https://invent.kde.org/sysadmin/release-tools/commit/55205d99c891db1c5e8980ebcd16b5f213d2c31b
>
> Please update the code to use RELEASE_SERVICE_VERSION as soon as possible.
>
> I think that there's something else somewhere that needs to change so that 
> the build.kde.org changes from "extragear" to "Applications" [both outdated 
> terms]. Sysadmin?

This should be done now, in the two commits that I CC'ed to this list.

Regards,
Ben

>
> Cheers,
>   Albert
>
> >
> > >
> > > Cheers,
> > >   Albert
> >
> > Thanks,
> >
> > Elvis
> >
> >
> > >
> > >>> Cheers,
> > >>>   Albert
> > >> Cheers,
> > >>
> > >> Elvis
> > >>
> > >>
> >  Thanks
> > 
> >  Cheers,
> >  Elvis
> > 
> > 
> > >>>
> > >>>
> > >
> > >
> > >
> >
>
>
>
>

[sysadmin/ci-tooling] local-metadata: Reflect move of KIO GDrive to KDENetwork (Release Service)

[Ben Cooksley]

Git commit 06aa01d57a9f02109da0cb2b835d7f9c6c2194f8 by Ben Cooksley.
Committed on 01/07/2020 at 07:34.
Pushed by bcooksley into branch 'master'.

Reflect move of KIO GDrive to KDENetwork (Release Service)

CCMAIL: release-team@kde.org

M  +3-4local-metadata/product-definitions.yaml

https://invent.kde.org/sysadmin/ci-tooling/commit/06aa01d57a9f02109da0cb2b835d7f9c6c2194f8

diff --git a/local-metadata/product-definitions.yaml 
b/local-metadata/product-definitions.yaml
index 85766c4..c73a552 100644
--- a/local-metadata/product-definitions.yaml
+++ b/local-metadata/product-definitions.yaml
@@ -130,6 +130,9 @@
 - match: "kde/applications/dolphin"
   to: "kfm-de...@kde.org"
   failuresOnly: false
+- match: "kde/kdenetwork/kio-gdrive"
+  to: "kfm-de...@kde.org"
+  failuresOnly: false
 - match: "kde/applications/kate"
   to: "christ...@cullmann.io"
   failuresOnly: true
@@ -162,7 +165,6 @@
   includes:
 - repositories:
   - "extragear/network/choqok"
-  - "extragear/network/kio-gdrive"
   - "extragear/office/kbibtex"
   - "extragear/pim/zanshin"
   - "extragear/sdk/clazy"
@@ -243,9 +245,6 @@
 - match: "extragear/graphics/digikam"
   to: "digikam-de...@kde.org"
   failuresOnly: false
-- match: "extragear/network/kio-gdrive"
-  to: "kfm-de...@kde.org"
-  failuresOnly: false
 - match: "extragear/sdk/clazy"
   to: "smart...@kde.org"
   failuresOnly: false

[sysadmin/repo-metadata] /: Move KIO GDrive from Extragear to Release Service (KDENetwork component)

[Ben Cooksley]

Git commit 1b902a61ada0251456b9ac4a6042fa4944fc63bf by Ben Cooksley.
Committed on 01/07/2020 at 07:34.
Pushed by bcooksley into branch 'master'.

Move KIO GDrive from Extragear to Release Service (KDENetwork component)

CCMAIL: release-team@kde.org

M  +4-2dependencies/dependency-data-kf5-qt5
M  +4-2dependencies/dependency-data-stable-kf5-qt5
M  +6-6dependencies/logical-module-structure
M  +1-1projects-invent/network/kio-gdrive/metadata.yaml

https://invent.kde.org/sysadmin/repo-metadata/commit/1b902a61ada0251456b9ac4a6042fa4944fc63bf

diff --git a/dependencies/dependency-data-kf5-qt5 
b/dependencies/dependency-data-kf5-qt5
index 85c122f7..da59c158 100644
--- a/dependencies/dependency-data-kf5-qt5
+++ b/dependencies/dependency-data-kf5-qt5
@@ -1205,6 +1205,10 @@ extragear/edu/gcompris: frameworks/kdoctools
 kde/kdenetwork/kget: kdesupport/qca
 kde/kdenetwork/kget: extragear/network/libktorrent
 
+# KIO GDrive
+kde/kdenetwork/kio-gdrive: kde/pim/libkgapi
+kde/kdenetwork/kio-gdrive: kde/kdenetwork/kaccounts-integration
+
 # Kopete
 kde/kdenetwork/kopete: kdesupport/qca
 kde/kdenetwork/kopete: frameworks/khtml
@@ -1359,8 +1363,6 @@ extragear/multimedia/kmplayer: kdesupport/phonon
 extragear/multimedia/kmplayer: frameworks/kmediaplayer
 
 # Extragear Network
-extragear/network/kio-gdrive: kde/pim/libkgapi
-extragear/network/kio-gdrive: kde/kdenetwork/kaccounts-integration
 extragear/network/konversation: kdesupport/qca
 extragear/network/choqok: kdesupport/qca
 extragear/network/choqok: frameworks/kdewebkit
diff --git a/dependencies/dependency-data-stable-kf5-qt5 
b/dependencies/dependency-data-stable-kf5-qt5
index 650e8008..d5bceb31 100644
--- a/dependencies/dependency-data-stable-kf5-qt5
+++ b/dependencies/dependency-data-stable-kf5-qt5
@@ -1204,6 +1204,10 @@ extragear/edu/gcompris: frameworks/kdoctools
 kde/kdenetwork/kget: kdesupport/qca
 kde/kdenetwork/kget: extragear/network/libktorrent
 
+# KIO GDrive
+kde/kdenetwork/kio-gdrive: kde/pim/libkgapi
+kde/kdenetwork/kio-gdrive: kde/kdenetwork/kaccounts-integration
+
 # Kopete
 kde/kdenetwork/kopete: kdesupport/qca
 kde/kdenetwork/kopete: frameworks/khtml
@@ -1358,8 +1362,6 @@ extragear/multimedia/kmplayer: kdesupport/phonon
 extragear/multimedia/kmplayer: frameworks/kmediaplayer
 
 # Extragear Network
-extragear/network/kio-gdrive: kde/pim/libkgapi
-extragear/network/kio-gdrive: kde/kdenetwork/kaccounts-integration
 extragear/network/konversation: kdesupport/qca
 extragear/network/choqok: kdesupport/qca
 extragear/network/choqok: frameworks/kdewebkit
diff --git a/dependencies/logical-module-structure 
b/dependencies/logical-module-structure
index 2318fa50..6d9c4595 100644
--- a/dependencies/logical-module-structure
+++ b/dependencies/logical-module-structure
@@ -1034,6 +1034,12 @@
 "kf5-qt5": "master",
 "stable-kf5-qt5": "release/20.04"
 },
+"kde/kdenetwork/kio-gdrive": {
+"stable-qt4": "",
+"latest-qt4": "",
+"kf5-qt5": "master",
+"stable-kf5-qt5": "1.3"
+},
 "kde/kdenetwork/kopete": {
 "stable-qt4": "Applications/17.08",
 "latest-qt4": "Applications/17.08",
@@ -1810,12 +1816,6 @@
 "kf5-qt5": "master",
 "stable-kf5-qt5": "5.0"
 },
-"extragear/network/kio-gdrive": {
-"stable-qt4": "",
-"latest-qt4": "",
-"kf5-qt5": "master",
-"stable-kf5-qt5": "1.3"
-},
 "extragear/base/atcore": {
 "stable-qt4": "",
 "latest-qt4": "",
diff --git a/projects-invent/network/kio-gdrive/metadata.yaml 
b/projects-invent/network/kio-gdrive/metadata.yaml
index 6614a9ef..527d8e20 100644
--- a/projects-invent/network/kio-gdrive/metadata.yaml
+++ b/projects-invent/network/kio-gdrive/metadata.yaml
@@ -2,6 +2,6 @@ description: KIO Slave to access Google Drive
 hasrepo: true
 identifier: kio-gdrive
 name: KIO GDrive
-projectpath: extragear/network/kio-gdrive
+projectpath: kde/kdenetwork/kio-gdrive
 repoactive: true
 repopath: network/kio-gdrive

Re: Calindori in release service

[Ben Cooksley]

On Mon, Jun 29, 2020 at 1:19 AM Dimitris Kardarakos  wrote:
>
> On June 26, 2020 12:55:25 AM GMT+03:00, Albert Astals Cid  
> wrote:
> >El dijous, 25 de juny de 2020, a les 17:25:25 CEST, Dimitris Kardarakos va 
> >escriure:
> >> On 24/6/20 11:48 μ.μ., Albert Astals Cid wrote:
> >> > El dimecres, 24 de juny de 2020, a les 18:44:14 CEST, Dimitris 
> >> > Kardarakos va escriure:
> >> >> Hello everyone,
> >> >>
> >> >> I would like Calindori to be included in the release service. It has
> >> >> been in kdereview since April and I think it's time for a stable 
> >> >> release.
> >> >
> >> > It seems you haven't had [m]any standalone releases, right?
> >> >
> >> If you mean Calindori releases, you can find them here:
> >> https://invent.kde.org/plasma-mobile/calindori/-/releases
> >>
> >> If you mean a KDE application stable release, the project should have
> >> been either in extragear or the release service, do I miss something?
> >> Calindori is still in kdereview.
> >> > We usually encourage new apps to do a few of those on their own since it 
> >> > allows them to do a faster cycle than our 4 months one, which sometimes 
> >> > for new apps is useful.
> >> >
> >> You suggest to move the application to extragear and make a couple of
> >> releases?
> >
> >That's our typical suggestion for "new" apps so they can iterate faster than 
> >the release service provides for.
> >
> >But as said, that's just a suggestion, not mandatory at all.
>
> OK let's go for standalone (extragear) release. Is there any sysadmin task 
> needed before I start executing the steps of 
> https://community.kde.org/ReleasingSoftware?

The only adjustment we'll need to make will be to the repository
metadata to shift it from "playground" to "extragear".
Otherwise no other action is needed on our part.

>
>
> Dimitris

Cheers,
Ben

Re: Calindori in release service

[Ben Cooksley]

On Fri, Jun 26, 2020 at 3:56 AM Luigi Toscano  wrote:
>
> Dimitris Kardarakos ha scritto:
> > On 24/6/20 11:48 μ.μ., Albert Astals Cid wrote:
> >> El dimecres, 24 de juny de 2020, a les 18:44:14 CEST, Dimitris Kardarakos 
> >> va escriure:
> >>> Hello everyone,
> >>>
> >>> I would like Calindori to be included in the release service. It has
> >>> been in kdereview since April and I think it's time for a stable release.
> >>
> >> It seems you haven't had [m]any standalone releases, right?
> >>
> > If you mean Calindori releases, you can find them here:
> > https://invent.kde.org/plasma-mobile/calindori/-/releases
>
> Proper releases should follow this process:
> https://community.kde.org/ReleasingSoftware
>
> Releases shouldn't use invent. Without following the process the translations
> have been excluded.

Please note that the Releases functionality of Gitlab (at
invent.kde.org) can still be used, as long as the translations are
pushed to the tag that is used (as David does for Frameworks I
believe)
Archives should still be provided on download.kde.org though yes.

>
> Applictions which have not passed review ends up inside
> https://download.kde.org/unstable. After passing the review, they can ends up
> either on https://download.kde.org/stable or
> https://download.kde.org/unstable, depending whether the release is a stable
> one (non-beta/RC).
>
>
>
> --
> Luigi

Cheers,
Ben

Re: New Framework Review: KDAV

[Ben Cooksley]

On Sun, Jun 14, 2020 at 8:03 PM Volker Krause  wrote:
>
> With both 20.04.2 and 5.71.0 out I think it's now time to do this move.
>
> What extra steps do we need to take now that the framework/application
> distinction exists in Gitlab as well? I guess this is the first case of a
> post-migration move. Also, what is the impact on the 20.04.3 release when we
> move this in Gitlab?

You'll need to file a Sysadmin ticket requesting we relocate the
repository from it's current home in pim/ to frameworks/
Gitlab will provide a redirect for this automatically, so existing
urls and clones won't be affected by this - although they will be
given a notice that it has moved.

Systems such as scripty won't be impacted by this as they use the
stable repository identifier.

In terms of the Release Service 20.04.3 release, Albert/Christoph will
need to comment on this.

>
> Thanks,
> Volker

Cheers,
Ben

>
> On Sunday, 24 May 2020 08:52:17 CEST Volker Krause wrote:
> > The remaining issues that didn't change ABI anymore (movable value types,
> > hide private methods/slots inside the private classes, etc) have long since
> > been addressed.
> >
> > I think there's two possible time slots to actually execute the move to
> > frameworks now:
> > * ASAP, for the June release.
> > * For the July release, just in time for the 20.08 dependency freeze.
> >
> > Opinions?
> >
> > Thanks,
> > Volker
> >
> > On Saturday, 4 April 2020 17:32:19 CEST Volker Krause wrote:
> > > Thanks for the review! We are cutting it close again with the 20.04
> > > deadline, but fortunately most of these findings aren't ABI-breaking :)
> > >
> > > The result was discussed in more detail at the (virtual) PIM sprint,
> > > summary below for the record.
> > >
> > > On Saturday, 4 April 2020 16:20:21 CEST Kevin Ottens wrote:
> > > > Hello,
> > > >
> > > > On Saturday, 9 November 2019 12:33:54 CEST Volker Krause wrote:
> > > > > during Akademy there was a request to promote KDAV from KDE PIM to
> > > > > Frameworks for use by Plasma Mobile. KDAV is a framework that
> > > > > implements
> > > > > the CalDav/ CardDav/GroupDav protocol on top of KIO's WebDav support.
> > > > > It
> > > > > would be classified as a functional tier 3 framework.
> > > > >
> > > > > So far we have fixed a number of obvious ABI-compatibility issues,
> > > > > removed
> > > > > QtXml[Patterns] usage from the public interface and relicensed GPL
> > > > > parts
> > > > > (apart from a bit of test code) to LGPL. The next step would be a more
> > > > > thorough review to identify changes necessary before becoming a
> > > > > Framework.
> > > > >
> > > > > To avoid the last minute invasive changes we ended up doing for
> > > > > KCalendarCore, I'd propose the following timeline:
> > > > >
> > > > > - identify and implement all necessary changes to the API and ABI
> > > > > until
> > > > > the
> > > > > 20.04 Application release (that includes the still necessary move to
> > > > > the
> > > > > KF5 library namespace).
> > > >
> > > > I'm likely late to the party, but here is what I found by looking at
> > > > KDAV
> > > >
> > > > master today (first day of the KDE PIM sprint):
> > > >  * There's a few private methods or Q_SLOTS that I'd hide completely by
> > > >
> > > > moving them to the d-pointer, for the slots we're using type safe
> > > > connects
> > > > so they don't even need to be marked as slots at all;
> > >
> > > Cosmetic with no ABI impact, we can do that post 20.04 still.
> > >
> > > >  * Is it worth making DavCollection moveable? It's only copyable right
> > > >  now;
> > >
> > > Probably yes, that's new API with no ABI break, so we can do that post
> > > 20.04 as well.
> > >
> > > >  * We might want to do something about "ctag" in DavCollection it's a
> > > >  bit
> > > >
> > > > obscure as a name (and the API doc doesn't help), also it seems to not
> > > > be
> > > > an official standard (while being widely supported) and there's the
> > > > sync-token mechanism which has a RFC (RFC6578);
> > >
> > > I have no idea what ctag is (I am only doing the technical work needed to
> > > turn this into a framework, I didn't write this library).
> > >
> > > >  * Why isn't DavCollectionModifyJob using DavCollection somehow? (might
> > > >  just
> > > >
> > > > be my ignorance but I find it surprising that it is solely based on a
> > > > property mechanism);
> > >
> > > I think this is to be able to control which properties get changed, rather
> > > than sending the full set of them.
> > >
> > > >  * DavCollections(Multi)FetchJob has a mysterious "protocol" parameter
> > > >  on
> > > >
> > > > its collectionDiscovered signal, is it really necessary? if it has to
> > > > stay,
> > > > shouldn't be at least documented? or at least a safer type than int?
> > >
> > > Fixed in https://phabricator.kde.org/D28564 and
> > > https://phabricator.kde.org/ D28566
> > >
> > > > * DavCollectionsMultiFetchJob is inconsistent as it's not using
> > > > Q_DECLARE_PRIVATE;
> > >
> > > That's due to 

Re: KDE releases 20.04.1 delayed to Friday 15-May-2020

[Ben Cooksley]

On Wed, May 13, 2020 at 10:05 AM Christoph Feck  wrote:
>
> Hi packagers,

Hi Christoph,

>
> the 20.04.1 releases from the KDE Release Service will be published on
> Fri 15-May-2020 (instead of Thu 14-May as initially planned).
>
> Reasons:
> - give the promo and translation teams a day more time to prepare the
> announcement text (I failed to submit a changelog yesterday)
> - avoid clashing with the Plasma 5.19 beta release at the same day
> (clash noticed today by the Plasma release team)
>
> git log v20.04.0..v20.04.1 at https://phabricator.kde.org/P598
> (Some noteworthy changes have been added as a comment there)
>
> https://kde.org/announcements/changelog-releases.php?version=20.04.1
>
> (CC'ing sysadmins to check if this may conflict with preparing git
> infrastructure changes)

If you could please ensure that any operations with regards to the
release are completed by 8pm CEST to avoid any conflicts with
preparations for the migration that would be appreciated.

Should for any reason operations need to take place after that, the
release will need to be postponed to Friday next week.

>
> --
> Christoph Feck
> KDE Release Team

Cheers,
Ben

Re: Pim package + qt 5.13

[Ben Cooksley]

On Tue, May 12, 2020 at 5:18 PM laurent Montel  wrote:
>
> Hi,

Hi Laurent,

> For info in 1 week I will switch to qt5.13 for pim package.

I'm afraid you need to give two weeks notice for a change such as this
per the guidelines on CI dependency changes.
Also, this hasn't been notified to Sysadmin (either via ticket or
otherwise) so the two week clock on this has not started yet.

>
> Regards

Cheers,
Ben

>
> --
> Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53,
>  www.kdab.fr KDAB - The Qt, C++ and OpenGL Experts - Platform-independent
> software solutions
>
>

Re: Fwd: No announcements for KDE Applications 20.04

[Ben Cooksley]

On Sun, Apr 26, 2020 at 9:42 AM Paul Brown  wrote:
>
> On sábado, 25 de abril de 2020 21:04:12 (CEST) Ben Cooksley wrote:
> > Hi Release Team,
> >
> > Any ideas about the below?
> >
> > Cheers,
> > Ben
>
> FWIW the announcement text is here:
>
> https://kde.org/announcements/releases/2020-04-apps-update/

Okay, so sounds like we just missed updating the announcements index,
and sending an email to kde-annou...@kde.org?

>
> Cheers
>
> Paul

Cheers,
Ben

> --
> Promotion & Communication
>
> www: http://kde.org
> Mastodon: https://mastodon.technology/@kde
> Facebook: https://www.facebook.com/kde/
> Twitter: https://twitter.com/kdecommunity
> LinkedIn: https://www.linkedin.com/company/kde
>
>

Fwd: No announcements for KDE Applications 20.04

[Ben Cooksley]

Hi Release Team,

Any ideas about the below?

Cheers,
Ben

-- Forwarded message -
From: Евгений Попов 
Date: Sat, Apr 25, 2020 at 11:47 PM
Subject: No announcements for KDE Applications 20.04
To: 


Hello.

A few days ago, I received updates for KDE Applications to version
20.04, but still haven't received an announcement about this, although
I have subscribed for the kde-announce service. Also, there are no
announcement on the KDE Announcements page. Maybe you forgot to
publish them or something broke?
-- 
Best regards, Eugene Popov

Re: anyone using releaseme module releasing

[Ben Cooksley]

On Fri, Apr 24, 2020 at 9:59 PM Harald Sitter  wrote:
>
> On Fri, Apr 24, 2020 at 11:46 AM Jonathan Riddell  wrote:
> >
> > I'm not using it.
> >
> > And it would be worth querying if the modules in repo-metadata are useful 
> > at all beyond playground, kdereview, stuff-we-care-about and unmaintained.  
> > Currently there's several modules in the stuff-we-care-about category most 
> > of which aren't useful categorisations of anything and the names are 
> > obsolete.
>
> +1

Please note that for the purposes of ease of discovery and developers
being able to see the reviews relevant to them, we are intending to
organise repositories on Gitlab on the basis of the subgroups you're
proposing to get rid of here (graphics, multimedia, network, plasma,
etc)

Cheers,
Ben

Re: 2 kirigami fixes for a point release

[Ben Cooksley]

On Mon, Feb 17, 2020 at 10:55 AM Friedrich W. H. Kossebau
 wrote:
>
> Sorry, no time to rewrite to make this short.
>
> Am Mittwoch, 12. Februar 2020, 21:59:32 CET schrieb Nate Graham:
> > [+ frameworks and plasma mailing lists]
> >
> > On 2020-02-12 11:31, Albert Astals Cid wrote:
> > > El dimecres, 12 de febrer de 2020, a les 15:37:09 CET, Nate Graham va
> escriure:
> > >> On another note, I have to admit I'm starting to doubt how well our LTS
> > >> Plasma product works without a corresponding LTS frameworks release to
> > >> support it. We can fix bugs in software that uses the Plasma release
> > >> schedule till the cows come home, but if the bug is in Frameworks, users
> > >> are stuck with it forever since LTS distros don't typically ship new
> > >> Frameworks releases.
>
> Yes, this has been questioned a few times. Also seeing Plasma LTS used
> together with a non-LTS Qt is a bit strange.
> But somehow it seems there has not been enough pain for those using the Plasma
> LTS to change something. Possibly because distributions simply backport
> important bug fixes for KF themselves, kind of maintaining their own KF LTS
> version of the KF version they pinpointed to when they froze the ingredients
> to their OS. Because they are used to do this for other projects as well, and
> so miss this could be done in cooperation with upstream.
>
> IMHO distributions using Plasma LTS, Plasma team & other stakeholders should
> team up here and maintain a matching LTS branch of Frameworks together at the
> central KDE repos together. Well, and a version also satisfying other clients
> of KF, like non-workspace applications from KDE.
>
> It's not a reason to change normal KF release cycle.
>
> BTW, we release our software in variants of GPL. We give distributions lots of
> rights by that license to do with the source code what they like, not what
> pleases us as authors. So we want to do cooperation here, not get into any
> form of commandeering them, as it starts sounding elsewhere in this thread.
>
> If unsatisfied with the quality, make Plasma a trademark and hand it out only
> to distributions which are complying with the standards the Plasma team is
> fine with ;)
> Oh, look, an iceweasel is running over there... ;)

Another option is to withdraw the privilege of pre-release access to
packages from the distributions that don't comply.

>
> > >> Yes yes, they should, and all that--but they don't.
> > >>
> > >> It seems like we either need to:
> > >> - Work on convincing these distros to ship Frameworks versions in a
> > >> rolling manner to their LTS users
> > >> - Provide an LTS Frameworks product that can receive bugfixes and get
> > >> point releases, to support the Plasma LTS product
> > >> - Stop misleadingly offering a Plasma LTS product, since everything in
> > >> it that comes from Frameworks isn't actually LTS
> > >
> > > This should not matter, Plasma LTS is built on *lots* of other libraries
> > > that are not LTS either.
> > >
> > > If it matters is because the quality of KF5 releases are not good, that's
> > > what should be fixed IMHO.
> > Yes, the Frameworks 5.67 release was indeed was quite buggy and
> > regression-filled from a Plasma perspective :(
> >
> > However buggy releases are the proximate cause, not the root cause. We
> > have to ask: what causes buggy releases?
> >
> > I would argue that bugginess is baked into the Frameworks product by
> > virtue of its very fast one-month release cycle and lack of beta
> > periods, as there are for apps and Plasma. No matter how diligent patch
> > review is, regressions always sneak in; that's why QA and beta-testing
> > exist.
>
> This assumes the master branch of KF modules serves the purpose of beta
> testing. My understanding is: it does not. And could not be, for the very
> reason you gave, too little time and too few testers.
>
> The master branch's purpose is mainly to collect all changes for the next
> release, and serve as reference when merging dependent changes across multiple
> repos for CI. It should be in the state of "always releaseable".
>
> Which also means patches going in should have seen a beta period by the people
> doing the patches _before_ merging them, and be well understood in their
> potential side-effects. Yes, this also means that for cross-repo/products
> developer should have first done some testing for some time with locally
> patched variants of all affected repos, if unsure about their changes (say,
> removing an unused variable is well understood in effect scope and does not
> need lots of testingi).
> But by default crowd-sourcing the QA to fellow developers also working against
> current master and wanting to test-drive their own changes is not the way to
> go. For one they do not know they should test certain things and thus might
> not even get close to things, thus not do any testing, or it will conflict
> with their own work, when they cannot be sure it was their own change or
> someone else's which breaks 

Re: 2 kirigami fixes for a point release

[Ben Cooksley]

On Mon, Feb 17, 2020 at 10:43 AM Albert Astals Cid  wrote:
>
> El diumenge, 16 de febrer de 2020, a les 22:34:51 CET, David Faure va 
> escriure:
> > On dimanche 16 février 2020 22:17:17 CET Albert Astals Cid wrote:
> > > This is their fault, they as a distribution have decided to support a 
> > > random
> > > KDE Frameworks version for longer than we do support it, so they are the
> > > ones that should be the job of supporting it.
> > >
> > > It's like you are trying to say we should be doing the distributions jobs,
> > > what we should be doing is doing our job which is making the best software
> > > we can, not spending time accomodating decisions that somebody else took
> > > for us, and since distributions often only bring us pain in the shape of
> > > not updating versions, etc. IMHO what we should be doing is moving away
> > > from distributions model and more into the snap/flatpak model in which we
> > > control what we give our users.
> > >
> > > Sadly flatpak doesn't work for non applications and snap is
> > > Ubuntu-only-not-really-but-yes-really so for Plasma this doesn't really
> > > solver the problem so maybe we should just finally tell our users to start
> > > using the good distributions if they care about their user experience. By
> > > good meaning those with a rolling KDE software suite or those that 
> > > actually
> > > do backport fixes to the version they have randomly decided to lock onto.
> >
> > At the same time, we can only successfully convince distributions to upgrade
> > to the monthly KF5 releases if they are stable and don't come with
> > regressions. I believe this is true for most of the frameworks, but I'm not 
> > so
> > sure about kirigami/qqc2-desktop-style, based on what I hear (not just the
> > recent issue).
> >
> > Before blaming distros, I believe we have our own backyard to take care of,
> > with for sure more systematic use of code reviews and possibly more 
> > automated
> > testing, for those frameworks (for the latter I guess that QtQuick doesn't
> > make it easy, but that's part of the problem...).
>
> Maybe i explain myself wrongly, i'm not blaming distros at all.
>
> They made a decision, we/I may agree with them or not, that's *my/our* 
> problem, what I was disagreeing is to us having to do extra work because 
> someone elses (the distros) decision.

Unfortunately users will sadly blame us, saying KDE software is
buggy/broken/etc.
It therefore falls on us to apply pressure on the distributions making
bad decisions and make them correct them.

Those distributions that provide a bad experience to our users, and
refuse to fix it, are working against us and the goals we are trying
to achieve.

(I'm not saying that we should bow down to flawed, short sighted and
broken distribution policies here, if anyone is bending it should be
their policies bending down to us)

>
> And yes, totally, we need more autotests, and moving to gitlab so tests are 
> finally run *before* merging stuff.

That will come once we have migrated code management and review to Gitlab yes.
It wouldn't have helped in the case of Kirigami sadly as there are no
unit tests for the things which were broken, but i'm sure it will help
in other areas for sure.

>
> Cheers,
>   Albert

Cheers,
Ben

>
> >
> >
>
>
>
>

Re: 2 kirigami fixes for a point release

[Ben Cooksley]

On Sun, Feb 16, 2020 at 8:35 AM Nate Graham  wrote:
>
> On 2020-02-15 11:55, Ben Cooksley wrote:
> > My point above was that the version you decide to freeze on should
> > only be the version you depend on during development.
> > The version you depend on when you release will be the next release of
> > Frameworks (so by freezing on 5.66 for development, it should have had
> > a release-day dependency of 5.67)
> >
> > The release of Plasma should then take place shortly after the
> > Frameworks version you have a release-day dependency on.
> >
> > You stagger it like this to ensure that developers are performing a
> > full burn in of the Frameworks version for several weeks on their
> > systems, and to ensure that all the problems they find end up in the
> > Frameworks that users will have on their systems.
>
> None of this makes a difference for distros that ship LTS Plasma don't
> ship newer Frameworks versions. No matter how much testing you do, some
> bugs in Frameworks will slip through and need to be fixed after the
> release. But the frameworks release cycle has no concept of the
> post-release bugfix like Apps and Plasma do; instead the expectation is
> that the distro will just ship a new Frameworks version in a month. This
> expectation does not match the reality for the distros that want to ship
> an LTS plasma version and do not ship newer Frameworks versions.

>From my understanding distributions were for the most part happy to
ship Frameworks updates as they came.

While I have not been able to find the thread in question where this
was discussed, I would be very surprised if the distributions you
noted below were not part of that discussion.

Should this have changed, or they have reversed their initial
decision, then we will need to have a conversation with that
distribution as to why they believe it is more appropriate to be
shipping known buggy software and to refuse to ship the fixes to those
bugs.

Should they have initially agreed to distribute the updates and
subsequently changed their policy on it without notifying us then that
also needs to be discussed with them and I think they owe us an
explaination as to why they failed to discuss it with us prior to them
changing their stance (and we changed our policies isn't good enough
as an explaination)

>
>
> > As for the distributions that are refusing to update Frameworks, do
> > you have a list of those distributions?
> > If they're providing a poor experience to our users then we at the
> > very least should ensure we steer people away from them.
>
> Oh, you know, just some weird, unimportant little ones, like Debian,
> Ubuntu/Kubuntu, and openSUSE Leap. ;-) We should definitely make sure
> that our users don't use *those*; it's not like they're the big heavy
> hitters of the Linux world that are used in large numbers by
> corporations and shipped on hardware or anything. :)
>
> Nate

Cheers,
Ben

Re: 2 kirigami fixes for a point release

[Ben Cooksley]

On Sat, Feb 15, 2020 at 8:10 AM Nate Graham  wrote:
>
> On 2020-02-13 00:42, Ben Cooksley wrote:
> > A better way of approaching this would be to freeze the Frameworks
> > version you are going to require API wise at an earlier point in the
> > Plasma development cycle. This would allow for a full Frameworks
> > release cycle to pass where bugs encountered during the lead up to the
> > Plasma release can be fixed.
> >
> > This version of Frameworks would then be the one that Plasma hard depends 
> > on.
>
> We do this; Plasma 5.18 has a minimum Frameworks dependency of 5.66. See
> https://community.kde.org/Schedules/Plasma_5#Support_status_by_Release_Series
>
> The problem here isn't so much API breaks but rather major bugs and UI
> regressions. if a framework has a very visible bug or UI regression in
> 5.66 of the kind that we would really like to fix, but LTS distros
> freeze on that version, then LTS users will be stuck with that issue
> forever unless we make a frameworks point release or cajole distro
> packagers to backport the fix.
>
> Rolling release distro users will first see Plasma 5.18 with Frameworks
> 5.67, so if that frameworks version has a major bug or UI regression, it
> will take a month for the fix to land in users' hands whereas if the
> issue were in Plasma itself, we could fix it immediately and users would
> get the fix in a week (the first point release is one week after the .0
> release).
>
> My point is that the schedules just don't really match up if we want to
> present a polished finished product and continue to fix bugs for the
> lifetime of an LTS release.
>

My point above was that the version you decide to freeze on should
only be the version you depend on during development.
The version you depend on when you release will be the next release of
Frameworks (so by freezing on 5.66 for development, it should have had
a release-day dependency of 5.67)

The release of Plasma should then take place shortly after the
Frameworks version you have a release-day dependency on.

You stagger it like this to ensure that developers are performing a
full burn in of the Frameworks version for several weeks on their
systems, and to ensure that all the problems they find end up in the
Frameworks that users will have on their systems.

As for the distributions that are refusing to update Frameworks, do
you have a list of those distributions?
If they're providing a poor experience to our users then we at the
very least should ensure we steer people away from them.

>
> Nate

Regards,
Ben

Re: 2 kirigami fixes for a point release

[Ben Cooksley]

On Thu, Feb 13, 2020 at 9:00 PM Christoph Feck  wrote:
>
> On 02/13/20 08:42, Ben Cooksley wrote:
> > Part of the issue here is that Plasma has been known to add API to
> > Frameworks and then immediately, without any delay, start using it
> > (pretty much always breaking CI in the process)
> >
> > This means that other changes are likely being pushed into Frameworks
> > by Plasma with very little delay as well.
> >
> > Consequently this means stuff is landing in Framework repositories up
> > to the very moment it is released - a release that the next version of
> > Plasma (LTS) then depends on.
> >
> > A better way of approaching this would be to freeze the Frameworks
> > version you are going to require API wise at an earlier point in the
> > Plasma development cycle. This would allow for a full Frameworks
> > release cycle to pass where bugs encountered during the lead up to the
> > Plasma release can be fixed.
>
> You can find bugs in new code best if you are actually using it. I doubt
> that delaying using new API would help much.

The point here was that when new API is added, it has to be added much
earlier in the cycle, so that anything using it gets at a minimum a
full month to cycle among our developers and have all the issues
worked out - in the next release which is the one that Plasma actually
depends on.

Currently it is added to Frameworks and started to be used
immediately, when Plasma has already released it's first Beta - giving
little chance for code to be run on developer systems before it hits
end users.

Cheers,
Ben

Re: 2 kirigami fixes for a point release

[Ben Cooksley]

On Thu, Feb 13, 2020 at 10:00 AM Nate Graham  wrote:
>
> [+ frameworks and plasma mailing lists]
>
>
> On 2020-02-12 11:31, Albert Astals Cid wrote:
> > El dimecres, 12 de febrer de 2020, a les 15:37:09 CET, Nate Graham va 
> > escriure:
> >> Personally I think it would be nice to have
> >> 86f988434cd657e77cc9429e78f7290ce6b5713d since otherwise LTS Plasma
> >> users will be hitting it for the next few years.
> >>
> >> ---
> >>
> >> On another note, I have to admit I'm starting to doubt how well our LTS
> >> Plasma product works without a corresponding LTS frameworks release to
> >> support it. We can fix bugs in software that uses the Plasma release
> >> schedule till the cows come home, but if the bug is in Frameworks, users
> >> are stuck with it forever since LTS distros don't typically ship new
> >> Frameworks releases.
> >>
> >> Yes yes, they should, and all that--but they don't.
> >>
> >> It seems like we either need to:
> >> - Work on convincing these distros to ship Frameworks versions in a
> >> rolling manner to their LTS users

Can we please have a list of the offending distributions?

> >> - Provide an LTS Frameworks product that can receive bugfixes and get
> >> point releases, to support the Plasma LTS product
> >> - Stop misleadingly offering a Plasma LTS product, since everything in
> >> it that comes from Frameworks isn't actually LTS
> >
> > This should not matter, Plasma LTS is built on *lots* of other libraries 
> > that are not LTS either.
> >
> > If it matters is because the quality of KF5 releases are not good, that's 
> > what should be fixed IMHO.
>
> Yes, the Frameworks 5.67 release was indeed was quite buggy and
> regression-filled from a Plasma perspective :(

Looking at the respin requests I see the following Frameworks as being
problematic:

- Kirigami
- QQC2 Desktop Style

This is only a small number of Frameworks.

>
> However buggy releases are the proximate cause, not the root cause. We
> have to ask: what causes buggy releases?

Part of the issue here is that Plasma has been known to add API to
Frameworks and then immediately, without any delay, start using it
(pretty much always breaking CI in the process)

This means that other changes are likely being pushed into Frameworks
by Plasma with very little delay as well.

Consequently this means stuff is landing in Framework repositories up
to the very moment it is released - a release that the next version of
Plasma (LTS) then depends on.

A better way of approaching this would be to freeze the Frameworks
version you are going to require API wise at an earlier point in the
Plasma development cycle. This would allow for a full Frameworks
release cycle to pass where bugs encountered during the lead up to the
Plasma release can be fixed.

This version of Frameworks would then be the one that Plasma hard depends on.

>
> I would argue that bugginess is baked into the Frameworks product by
> virtue of its very fast one-month release cycle and lack of beta
> periods, as there are for apps and Plasma. No matter how diligent patch
> review is, regressions always sneak in; that's why QA and beta-testing
> exist.
>
> However because Frameworks has no explicit beta period, the only people
> performing QA are those who live on master all the time. The amount of
> time for these people to catch regressions can be as short as one day,
> for changes committed right before tagging. Even for commits at the very
> beginning of a Frameworks release cycle, there will be a maximum of one
> month before they ship to users. There simply isn't enough time to
> provide adequate QA for Frameworks releases, and the pool of people
> doing it is too small.
>

Changes with the potential to have an impact like that shouldn't be
going in a day or two before the tagging/release.

> Making users be the QA is mostly okay for rolling release distros whose
> users are willing to take on that role: regressions get found and fixed
> in the next version and users receive the fixes in one month. But this
> model breaks down for LTS release distros that freeze on a specific
> frameworks version. If the version they've frozen on is buggy, that's
> it. It's buggy forever, unless their we make point releases or their
> already overworked packagers go out of the way to search for and
> backport fixes.
>
> The Frameworks release model just doesn't fit for discrete release
> distros, especially for the LTS releases. Sometimes it works out better
> than other times, but it is a fundamental incompatibility when the
> product wants customers to ship new releases continuously, but the
> customers want the product frozen to one version with only safe bugfixes
> shipped after that.
>
> Personally I think a lengthier release cycle and discrete beta periods
> would really help Frameworks, even in the absence of interest in
> creating a product more aligned to our LTS-using customers.
>
> Nate

Regards,
Ben

Re: KDE release 19.12.2 packages available for packagers

[Ben Cooksley]

On Tue, Feb 4, 2020 at 10:49 PM Christoph Feck  wrote:
>
> Hello packagers,
>
> *.tar.xz files are available at "stable/release-service/19.12.2".
>
> Known issue:
> - kwordquiz failed to build on Windows for unknown reasons, see
> https://build.kde.org/job/Applications/view/Everything%20-%20stable-kf5-qt5/job/kwordquiz/job/stable-kf5-qt5%20WindowsMSVCQt5.14/

The cause of this is known and is the result of changes in Frameworks
to eliminate the dependency on D-Bus.
It also affects Dr Konqi, Ruqola and Skrooge.

The correct fix for this is in Frameworks, so it shouldn't pose a
problem for the Applications release.

>
> Release is planned for Thursday.
>
> Preliminary v19.12.1..v19.12.2 changelog at
> https://kde.org/announcements/changelog-releases.php?version=19.12.2
>
> REVISIONS_AND_HASHES at https://phabricator.kde.org/P538
>
> My public key at
> http://pgp.mit.edu/pks/lookup?op=get=0xF23275E4BF10AFC1DF6914A6DBD2CE893E2D1C87
>
> Thanks,
> Christoph Feck

Cheers,
Ben

Re: Add kdeconnect-kde to release service

[Ben Cooksley]

On Fri, Dec 13, 2019 at 6:19 AM Volker Krause  wrote:
>
> On Wednesday, 11 December 2019 17:09:11 CET Nicolas Fella wrote:
> > Hi,
> >
> > we would like for KDE Connect to be included in the release service
> > beginning with the 20.04 release.
> >
> > As discussed with Jonathan I've moved the metadata to from extragear/network
> > to kde/kdeutils.
> >
> > I'm unsure about whether kdeconnect-android should move too or stay in
> > extragear. I assume the release tooling is not prepared for releases to
> > Google Play. We usually had separate releases for Android since we cannot
> > align the rollout anyway.
>
> Mobile apps in the release service is a good question though, I am interested
> in that for KDE Itinerary too.
>
> I think in general it would be very nice to have those includable as well,
> following a standardized branching and versioning model and the associated
> i18n workflows makes sense as much there as it does for desktop.
>
> If at all the difference is in the distribution channels I think. For Linux-
> based mobile distros there is probably very little difference as well. Android
> can be different though, seeing three possible channels there:
> (1) our self-hosted F-Droid repos, currently for debug nightly builds from
> master, but presumably we could have those as well for release builds from the
> stable branch?

The way we structure Android builds would probably need some
improvement from how we have it at the moment (which is starting to
head in the direction of being a bit messy) to support that, but yes
it is possible.

> (2) upstream F-Droid: for this we need actual releases, not binaries, quite
> similar to Linux distros
> (3) Play Store: would probably benefit from (1), if that produces packages we
> can (manually) upload there directly, without needing separate builds or
> signing infrastructure

>From my understanding the whole reason why the Binary Factory was
doing signing of builds was to allow for things like uploading to the
Play Store...

>
> Rollout to (2) and (3) does not necessarily be in sync with the release,
> that's also not the case for many other distributions.
>
> So from that perspective I don't see much against including mobile apps.
> However, do we need a way to clearly mark them as such to avoid them being
> distributed on desktop? For Android-only cases like kdeconnect-android that's
> a non-issue, but Kirigami-based mobile apps often build fine on desktop too,
> but might offer a sub-standard user experience there (certainly the case for
> KDE Itinerary).
>
> Regards,
> Volker

Cheers,
Ben

Re: Add kdeconnect-kde to release service

[Ben Cooksley]

On Fri, Dec 13, 2019 at 6:44 AM Nicolas Fella  wrote:
>
> On Donnerstag, 12. Dezember 2019 18:17:45 CET Volker Krause wrote:
> > I think in general it would be very nice to have those includable as well,
> > following a standardized branching and versioning model and the associated
> > i18n workflows makes sense as much there as it does for desktop.
> >
> > If at all the difference is in the distribution channels I think. For Linux-
> > based mobile distros there is probably very little difference as well.
> For the Qt-based mobile apps that are also relevant on the desktop it makes
> sense to include them. kdeconnect-android is a bit special in the regard that
> it really is an Android-only app.
>
> > Android can be different though, seeing three possible channels there:
> > (1) our self-hosted F-Droid repos, currently for debug nightly builds from
> > master, but presumably we could have those as well for release builds from
> > the stable branch?
> Having stable releases in our repo is not something I see a use case for if
> they are also available from the official F-Droid, which is something I
> definitely want to see and am working on.
> > (2) upstream F-Droid: for this we need actual releases, not binaries, quite
> > similar to Linux distros
> What we need for this is 1) tagged releases in the git repository and 2) build
> scripts in the fdroid repository. I'm working on such a script for KTrip at
> the moment. Once this is accepted we can use it as a blueprint for other apps.
> AFAIU F-Droid is able to automatically update an app when a git tag is pushed,
> so releases wouldn't need action from the release team. The scripts would need
> some regular maintainance (checking for failures, adding/updating dependencies
> etc), but that would not need to be done by the release team.
> > (3) Play Store: would probably benefit from (1), if that produces packages
> > we can (manually) upload there directly, without needing separate builds or
> > signing infrastructure
> My idea is that additionally to the nightly builds binary factory also builds
> release builds, i.e. from stable branches/tags, compiled in release mode
> without debug symbols etc. Ideally upload would be done via some Google Play
> API, but I don't know if such API exists.

With the way Android builds are currently conducted (building every
single dependency from scratch each time) i'm opposed to doing this as
it would double what is already quite an expensive load on the system
already.

I'd like to see the Android build process optimised to let it reuse
the results for most dependencies (Frameworks come to mind in
particular) before we head in that direction.

>
> > So from that perspective I don't see much against including mobile apps.
> > However, do we need a way to clearly mark them as such to avoid them being
> > distributed on desktop? For Android-only cases like kdeconnect-android
> > that's a non-issue, but Kirigami-based mobile apps often build fine on
> > desktop too, but might offer a sub-standard user experience there
> > (certainly the case for KDE Itinerary).
> I disagree on this. In my opinion those apps should be treated like our usual
> desktop apps (part of the release service or not). Mobile distributions are
> usually derived from desktop distros in some form so having them directly
> availabe would benefit the Linux mobile ecosystem. Furthermore, the vision of
> Kirigami is applications that work well on both mobile and desktop systems and
> not having them available on "normal" distros would undermine this vision.
>
> Cheers
>
> Nico
>
>
>

Cheers,
Ben

Re: "Create branch for 19.12 releases" task in phabricator

[Ben Cooksley]

On Thu, Nov 14, 2019 at 10:39 AM Albert Astals Cid  wrote:
>
> So in created this task for myself and then made comments as i went through 
> it.

Hi Albert,

>
> https://phabricator.kde.org/T12002
>
> I think this helps since we just have to do the same for the next branching.
>
> Can anyone other than me read it (both description and comments) and please 
> tell me if they feel like they understand what should be done in case i get 
> tired of doing this?

I've taken a look through that and the process seems relatively
straight forward to me.

About the only thing I think we're missing there is a bit of
explaination as to what each step is for (make sure we don't miss any
bugfixes which didn't get merged to master from the soon to be old
stable, etc). This might help in the future if someone is wondering
why a given step is being done or what it is trying to achieve.

>
> Cheers,
>   Albert
>

Thanks,
Ben

Re: Killing KDE Applications

[Ben Cooksley]

On Sat, Oct 26, 2019 at 10:49 AM Albert Astals Cid  wrote:
>

Hi Albert,

> As Jonathan mentioned last month at Akademy we decided we wanted to kill the 
> "KDE Applications" product and transform it to being basically a "release 
> service" that we run, that happens to help making a release 215 independent 
> projects on the same day.
>
> Are we fine with going forward with this just with the Akademy discussion or 
> do we want to discuss it with the rest of the community (i'd say kde-devel)?

I'd say it's probably a good idea to have a discussion on a public
mailing list, if only to ensure people are well aware that this change
is happening.
For the most part it is just a promotion/labelling issue, so I don't
imagine it being much of a problem.

>
> Cheers,
>   Albert
>
>

Cheers,
Ben

Re: Deprecating Old Amarok Versions

[Ben Cooksley]

On Thu, Oct 3, 2019 at 6:32 AM Luigi Toscano  wrote:
>
> Boudewijn Rempt ha scritto:
> > On woensdag 2 oktober 2019 18:12:46 CEST Luigi Toscano wrote:
> >
> >> Regarding this new, different topic that you just brought up for 
> >> discussion,
> >> and waiting for some words from the remaining amarok contributors, if I 
> >> had to
> >> choose I'd advise to not deprecate the current amarok repository (whose 
> >> master
> >> is KF5-based) until we switch to Qt6.
> >
> > Nobody was talking about the repository; the proposal was to remove the 
> > tarballs of a qt4-based amarok.
> >
> I disagree, or at least there is a terminology problem.
>
> https://mail.kde.org/pipermail/release-team/2019-October/011546.html
> This answer talks about deprecating applications. All Qt4 stuff are already
> deprecated, and (with one sad exception) stopped shipping them. We don't
> extract their translations anymore (with one exception, hopefully not for 
> long).
>
> So there is really no further action item that needs to be taken, unless
> "deprecating" is interpreted in the way of "moving to unmaintained", hence my
> answer.
>
> Regarding the tarballs, I'm not sure we can remove them completely. You may
> argue that their content can be reconstructed from the git tags, but let's
> play it on the safe side and keep them somewhere, also for historical 
> reference.
>
> Should we move them to a separate place? Sure, why not. Just remember that
> this is going to be more work for the sysadmins, so it's up to them to decide
> when (also because some applications have mixed Qt4 and Qt5 tarballs in their
> /stable/ or /unstable/ directories). As I wrote, I think it should be more
> consistent than just moving one specific tarball, and that in general this
> move is not really going to provide us any relevant gain.

We already have such a place - the Attic. All releases that are
unsupported get moved to the Attic.
This happens more often for projects whose releases take up a large
amount of space, so it's quite possible that projects with just a
single source tarball still have tarballs that are quite old under
either stable/ or unstable/

Moving things to the Attic is fortunately a reasonably cheap operation.

Cheers,
Ben

>
> --
> Luigi
>
>

Re: Source Signing

[Ben Cooksley]

On Thu, Sep 19, 2019 at 1:24 PM Harald Sitter  wrote:
>
> At akademy we had a poorly attended bof about release artifact
> signing. Jonathan raised the concern that while we generally sign our
> stuff we do not actually verify the signatures properly so coverage
> and reliability is dodgy at best.
> This largely factors into what Friedrich raised a while ago in
> https://phabricator.kde.org/T11304.
>
> (The stuff below only partially affects kf5,apps,plasma as their
> release processes are slightly different...)
>
> To get a source tarball released any one person can create a tarball,
> upload it to the relevant server and file a syadmin ticket.
> It is then upon the sysadmins to decide on a case by case basis if a
> given person should be allowed to even make a release of our software.
> This is hugely informal.

It is correct that there is no formally defined list of people who are
allowed to make releases of a given package.
For the most part, the checking process is reliant upon our knowledge
of who is involved with what project.

>
> What's more as far as we are aware the sysadmins currently do not
> verify or require signatures, so if an identity account of a developer
> was compromised malicious releases could be uploaded and published.

It is correct that we do not validate the GPG signatures submitted to us.

>
> And following the delivery pipeline, the distributions then again have
> to employ informal checks to verify the signatures, if they verify
> them at all.
>
> To deal with these problems we, Albert, Jonathan and I, concluded that
> it would be a good idea to formalize this process. The sysadmins
> should keep a keyring of public "release keys", and before making
> their first (source) release developers need to request release
> permission. That is to say they need to pop their gpg key somewhere
> (e.g. gitlab) and sysadmins then need to "vet" this person before
> picking the gpg key into their keyring.
>
> When someone uploads a source tarball we can then require it to have
> an associated signature. Sysadmins can gpg-verify the signature and by
> extension the uploaded artifact. Because of the keyring this could be
> fully automated and replace the current (presumably manual) shasum
> checks and hopefully make sysadmin's life easier.

While the process is manual in so far as a Sysadmin has to look at it,
the process has by-and-large been automated.

When someone submits a file for release, we run each hash/filename
pair through a script, which takes three parameters:
1) The destination of the file
2) The hash of the file
3) The name of the file to be released.

The script then validates the hash, and if all is well prompts if it
is okay to proceed with moving the file to it's final destination.

This provides a reasonable degree of assurance that the file released
is the one that the person originally uploaded, but you are correct
that it does not defend against attacks where someone's Identity
account has been compromised.

>
> On the distribution side the keyring can be used to reduce the amount
> of trust-on-first-use that has to be put into a new key as the
> sysadmin's release keyring would only contain vetted keys,
> demonstrating some minimal trust already.
>
> An unfortunate side effect is that the release process gets yet
> another step: getting your gpg key verified by sysadmins. A one-time
> step, but a step nonetheless.
>
> Currently our stance is that none of this would apply to non-source
> releases because there may be conflicting signature systems already in
> place. Notable example is windows where .exes have their own signing
> system already, so requiring gpg on top of that is probably useless.
>
> TLDR: no source releases without gpg signature, sysadmins maintain
> public keyring of developers who are allowed to release and use it to
> verify uploads, distros can use keyring to verify downloads
>
> What are your thoughts?

This seems reasonable at first glance.

Given some of the submissions we receive, i'm a little hesitant to
fully automate the process (at least until we've worked out all
potential issues and have a reasonably strong system in place for
preventing bad things from happening)

With regards to the keyring itself however, how were you envisioning
this operating?

In terms of how it would operate - were you thinking of it as a "this
person is authorised to release any KDE software" or "this person is
authorised to release X, Y and Z bits of KDE software"?

>
> We'd still need to figure out what exactly vetting entails. Could be
> as simple as having access to a developer account on gitlab.

I've a few ideas on how this might work - part of which may involve
using GPG signed commits (which Gitlab has the ability to validate if
you let Gitlab know your key fingerprint)

>
> HS

Cheers,
Ben