[sysadmin/ci-images] /: Include more of GStreamer to ensure Kamoso has it's dependencies installed.

[Ben Cooksley]

Git commit 3994445c7dc82b9011adcb2d7ccc901320978963 by Ben Cooksley.
Committed on 11/10/2023 at 11:51.
Pushed by bcooksley into branch 'master'.

Include more of GStreamer to ensure Kamoso has it's dependencies installed.

CCMAIL: kde-devel@kde.org

M  +1-0suse-qt515/Dockerfile
M  +1-0suse-qt65/Dockerfile

https://invent.kde.org/sysadmin/ci-images/-/commit/3994445c7dc82b9011adcb2d7ccc901320978963

diff --git a/suse-qt515/Dockerfile b/suse-qt515/Dockerfile
index 4a6d266..09ae593 100755
--- a/suse-qt515/Dockerfile
+++ b/suse-qt515/Dockerfile
@@ -303,6 +303,7 @@ RUN zypper --non-interactive in --allow-vendor-change \
 pcre-devel \
 # xdg-portal-test-kde
 gstreamer-devel \
+gstreamermm-devel \
 # Haruna
 mpv-devel \
 # kscreenlocker
diff --git a/suse-qt65/Dockerfile b/suse-qt65/Dockerfile
index 03fc442..9ed9748 100644
--- a/suse-qt65/Dockerfile
+++ b/suse-qt65/Dockerfile
@@ -304,6 +304,7 @@ RUN zypper --non-interactive in --allow-vendor-change \
 aqbanking-devel \
 # xdg-portal-test-kde
 gstreamer-devel \
+gstreamermm-devel \
 # Haruna
 mpv-devel \
 # kscreenlocker

Re: KDE Gear projects with failing CI (master) (10 October 2023)

[Ben Cooksley]

On Wed, Oct 11, 2023 at 4:37 PM Albert Astals Cid  wrote:

> Please work on fixing them, otherwise i will remove the failing CI
> jobs on their 4th failing week, it is very important that CI is passing
> for
> multiple reasons.
>
> Bad news: We have 3 new repositories failing
>
> = FAILING UNIT TESTS =
>
> kate:
>  * https://invent.kde.org/utilities/kate/-/pipelines/497698
>   * tests are failing
>

This looks to be a regression within KConfig no?
Likely won't show up on a developer system as the tests are bailing out on
asserts (the CI system builds a full Debug build on all platforms except
Windows, with all the consequences of that - this being one of them)


>
> cantor:
>  * https://invent.kde.org/education/cantor/-/pipelines/497702
>   * flatpak is failing
>* Probably needs to be disbled until we have a KF6 capable flatpak?
>

Flatpak should be removed from applications that have gone Qt 6 only yes.


>
> kamoso:
>  * https://invent.kde.org/multimedia/kamoso/-/pipelines/497706
>   * suse is failing to find packages
>* some gstreamer packages need to be added to the CI image?
>
>
Will be fixed once I have the image rebuild completed.


>
>
> Cheers,
>   Albert
>

Thanks,
Ben

Re: KDE Gear projects with failing CI (release/23.08) (10 October 2023)

[Ben Cooksley]

On Wed, Oct 11, 2023 at 4:45 PM Albert Astals Cid  wrote:

> Please work on fixing them, otherwise i will remove the failing CI
> jobs on their 4th failing week, it is very important that CI is passing
> for
> multiple reasons.
>
> Bad news: We have lots of more repositories failing :/ But they are all
> flatpak, so not that terrible. Please see last weeks' discussion as to a
> proposed solution if you have time to work on it.
>
> = FAILING TO COMPILE =
>
> kamoso:
>  * https://invent.kde.org/multimedia/kamoso/-/pipelines/497748
>   * suse is failing to find packages
>* some gstreamer packages need to be added to the CI image?
>

Should be fixed shortly.


>
>
> = FAILING UNIT TESTS =
>
> konsole: (4th week)
>  * https://invent.kde.org/utilities/konsole/-/pipelines/497709
>   * freebsd_qt515 tests are still failing. I will be disabling them
>

I have removed the failing line of code which has fixed 1/2 of the tests.

The remaining DBus test will have to be fixed by a Konsole developer i'm
afraid, however I imagine "Program to run not set." may explain it in part.


>
> kate:
>  * https://invent.kde.org/utilities/kate/-/pipelines/497708
>   * tests are failing
>

See my other mail - looks like Kate is just collateral damage.


>
>
> = FLATPAK FAILING =
>
> We kind of maybe have a plan for that, but needs executing. Since no one
> has
> executed it and some of the tests are failing for the whole week i will be
> commenting them all out
>
> cantor
> kalgebra
> bomber
> bovo
> kapman
> katomic
> kblackbox
> kblocks
> kbounce
> kbreakout
> kdiamond
> kfourinline
> kgoldrunner
> kigo
> killbots
> kiriki
> kjumpingcube
> klickety
> klines
> kmahjongg
> kmines
> knavalbattle
> knetwalk
> kolf
> kollision
>

Sounds reasonable to me, for Qt 6 only applications at least.
Flatpak is not yet ready to make the jump to Qt 6.

Cheers,
Ben

Re: KDE Gear projects with failing CI (release/23.08) (10 October 2023)

[Ben Cooksley]

On Thu, Oct 12, 2023 at 2:35 AM Albert Astals Cid  wrote:

> El dimecres, 11 d’octubre de 2023, a les 12:03:56 (CEST), Ben Cooksley va
> escriure:
> > On Wed, Oct 11, 2023 at 4:45 PM Albert Astals Cid  wrote:
> > > Please work on fixing them, otherwise i will remove the failing CI
> > > jobs on their 4th failing week, it is very important that CI is passing
> > > for
> > > multiple reasons.
> > >
> > > Bad news: We have lots of more repositories failing :/ But they are all
> > > flatpak, so not that terrible. Please see last weeks' discussion as to
> a
> > > proposed solution if you have time to work on it.
> > >
> > > = FAILING TO COMPILE =
> > >
> > > kamoso:
> > >  * https://invent.kde.org/multimedia/kamoso/-/pipelines/497748
> > >
> > >   * suse is failing to find packages
> > >
> > >* some gstreamer packages need to be added to the CI image?
> >
> > Should be fixed shortly.
>
> Could it be that you installed the wrong thing? Seems to still be failing
>
> What we need AFAICS is gstreamer-plugins-base-devel
>

Nope, the image build hadn't been triggered, which i've now done.

Note that for anyone looking at porting to Qt 6 we can't rebuild that image
for the moment as SUSE is bumping up to Qt 6.6, which will end up being a
separate Docker image entirely.
Once they've finished building it I will start the bumping process (which
starts by building a new Docker image, then seeding the package registry,
then finally switching CI over - so please try to avoid making SIC/BIC
changes for the next week or so)


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

Re: Bringing Glaxnimate into KDE

[Ben Cooksley]

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

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

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


>
> Cheers,
> Carl
>

Cheers,
Ben


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

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

[Ben Cooksley]

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

Move Linux CI for Qt 6 over to Qt 6.6.

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

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

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

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

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

Transitioning to Qt 6.6 for Windows builds - Syndication build failure

[Ben Cooksley]

Hi all,

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

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

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

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

Thanks,
Ben

Gitlab update - CI future proofing required

[Ben Cooksley]

Hi all,

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

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

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

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

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

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

Thanks,
Ben

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

[Ben Cooksley]

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

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

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


>
> Greetings
> Christoph
>

Cheers,
Ben


>
> >
> > Thanks,
> > Ben
>

Re: Reviving lightdm-kde-greeter upstream

[Ben Cooksley]

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

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

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

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

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

Cheers,
Ben


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

Re: Reviving lightdm-kde-greeter upstream

[Ben Cooksley]

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

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

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

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


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

Cheers,
Ben


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

qmlonline.kde.org - Updates required

[Ben Cooksley]

Hi all,

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

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

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

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

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

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

Cheers,
Ben

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

[Ben Cooksley]

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

> Hi,
>

HI Shubham,


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

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

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


>
> Regards,

Shubham
>
>
Cheers,
Ben


> Sent with Proton Mail secure email.
>

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

[Ben Cooksley]

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

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

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

Cheers,
Ben


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

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

[Ben Cooksley]

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

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


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


>
> Regards,
> Shubham
>

Cheers,
Ben


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

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

[Ben Cooksley]

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

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

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


>
> Greetings
> Christoph
>
>
Cheers,
Ben

Re: Re: KDE Plasma 5.27 on OpenBSD

[Ben Cooksley]

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

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

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


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

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

[Ben Cooksley]

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

> On Dienstag, 2. Januar 2024 22:01:25 CET Albert Astals Cid wrote:
> > Please work on fixing them, otherwise i will remove the failing CI
> > jobs on their 4th failing week, it is very important that CI is passing
> for
> > multiple reasons.
> >
> > Bad news: 2 new repositories are failing :(
> >
> >
> > == Something is up with kdiagram ==
> >
> > kdepim-addons:
> >  * https://invent.kde.org/pim/kdepim-addons/-/pipelines/572121
>
> Build is still running on FreeBSD, but this should be fixed.
>
> > == Something is up with kweathercore ==
> >
> > kweather:
> >  * https://invent.kde.org/utilities/kweather/-/pipelines/572137
>
> This one is more complicated. KWeatherCore master is Qt6-only, but there
> is no
> branch for past releases, only tags. So the CI has no Qt5 build of it
> anymore,
> which however is needed for the Qt5-based KWeather build.
>
> The best I can think of right now is adding a dummy kf5 branch on the v0.7
> tag?
>

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


>
> Regards,
> Volker
>

Cheers,
Ben

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: Major CI changes - FreeBSD and Linux

[Ben Cooksley]

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

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

This has now been corrected and should be functional again.


>
> Thanks,
> Ben
>

Cheers,
Ben

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

[Ben Cooksley]

On Wed, Jan 24, 2024 at 9:36 AM Albert Astals Cid  wrote:

> Please work on fixing them, otherwise i will remove the failing CI jobs on
> their 4th failing week, it is very important that CI is passing for
> multiple reasons.
>
> Good news: 5 repositories got fixed
>
> Bad news: 2 repo still failing (1 with a different failure) and *10* new
> this week
>
>
> krecorder - 2nd week
>  * https://invent.kde.org/utilities/krecorder/-/pipelines/589469
>   * All the craft_android builds are broken
>

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

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


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

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


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

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

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

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


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

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


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


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


>


>
> Cheers,
>   Albert
>

Cheers,
Ben

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

[Ben Cooksley]

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

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


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

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

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

Cheers,
Ben


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

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

[Ben Cooksley]

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

> On Dienstag, 23. Januar 2024 21:35:56 CET Albert Astals Cid wrote:
> > Please work on fixing them, otherwise i will remove the failing CI jobs
> on
> > their 4th failing week, it is very important that CI is passing for
> > multiple reasons.
> >
> > Good news: 5 repositories got fixed
> >
> > Bad news: 2 repo still failing (1 with a different failure) and *10* new
> > this week
>
> KMime is fixed in all branches now, the test regression in akonadi-search
> in
> master is also fixed, but the general FreeBSD fallout breaking MySQL and
> PostgreSQL Akonadi tests remains.
>

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

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


>
> Regards,
> Volker


Cheers,
Ben

Re: Defining a developer name for our applications metadata

[Ben Cooksley]

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

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

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

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


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

Cheers,
Ben


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

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

[Ben Cooksley]

On Wed, Jan 31, 2024 at 12:12 PM Albert Astals Cid  wrote:

> Please work on fixing them, otherwise i will remove the failing CI jobs on
> their 4th failing week, it is very important that CI is passing for
> multiple reasons.
>
> Good news: 10 repositories that were failing are fixed :)
>
> Bad news: 6 repositories are still failing and 2 new repositories are
> failing
>
> gwenview - 2nd week
>  * https://invent.kde.org/graphics/gwenview/-/pipelines/594392
>   * FreeBSD is missing kImageAnnotator
>

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

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


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

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

With that fixed, Spectacle is happy again.


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

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


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

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


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

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


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

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


>
> Cheers,
>   Albert
>

Cheers,
Ben

Re: Automation & Systematization sprint in Berlin in late April

[Ben Cooksley]

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

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

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

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


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

Cheers,
Ben

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

[Ben Cooksley]

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

> On Mittwoch, 31. Januar 2024 00:12:20 CET Albert Astals Cid wrote:
> > Please work on fixing them, otherwise i will remove the failing CI jobs
> on
> > their 4th failing week, it is very important that CI is passing for
> > multiple reasons.
> >
> > Good news: 10 repositories that were failing are fixed :)
> >
> > Bad news: 6 repositories are still failing and 2 new repositories are
> > failing
> >
> >
> > akonadi-search - 2nd week
> >  * https://invent.kde.org/pim/akonadi-search/-/pipelines/594413
> >   * various tests are failing in FreeBSD
>
> Same as with 24.02, half-fixed by backporting https://invent.kde.org/pim/
> akonadi/-/merge_requests/171
> , the remaining
> issues are due to the missing
> MySQL support in QtSQL.
>

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

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


>
> Regards,
> Volker
>

Cheers,
Ben

Retirement of Binary Factory

[Ben Cooksley]

Hi all,

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

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

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

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

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

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

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

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

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

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

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

Thanks,
Ben

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

[Ben Cooksley]

On Wed, Feb 7, 2024 at 10:24 AM Albert Astals Cid  wrote:

> Please work on fixing them, otherwise i will remove the failing CI jobs on
> their 4th failing week, it is very important that CI is passing for
> multiple
> reasons.
>
> Good News: 7 failing repositories from previous report got fixed
>
> Bad news: 3 repositories are still failing and 11 new repositories started
> failing
>
>
> gwenview - 3rd week
>  * https://invent.kde.org/graphics/gwenview/-/pipelines/601196
>   * cfitsio SHA doesn't match on flatpak build
>
>
> dolphin - 2nd week
>  * https://invent.kde.org/system/dolphin/-/pipelines/601190
>   * flatpak fails in icon-not-found
>
>
> ark - 2nd week
>  * https://invent.kde.org/utilities/ark/-/pipelines/601200
>   * FreeBSD tests failed
>
>
> kdialog - NEW
>  * https://invent.kde.org/utilities/kdialog/-/pipelines/601189
>   * flatpak fails in icon-not-found
>
>
> kmag - NEW
>  * https://invent.kde.org/accessibility/kmag/-/pipelines/601207
>   * flatpak fails in icon-not-found
>
>
> kbackup - NEW
>  * https://invent.kde.org/utilities/kbackup/-/pipelines/601223
>   * flatpak fails in icon-not-found
>
>
> kirigami-gallery - NEW
>  * https://invent.kde.org/sdk/kirigami-gallery/-/pipelines/601366
>   * flatpak fails in icon-not-found
>
>
> kbounce - NEW
>  * https://invent.kde.org/games/kbounce/-/pipelines/601210
>   * flatpak fails because code requires an unreleased ECM
>
>
> kdiamond - NEW
>  * https://invent.kde.org/games/kdiamond/-/pipelines/601211
>   * flatpak fails because code requires an unreleased ECM
>
>
> kmahjongg - NEW
>  * https://invent.kde.org/games/kmahjongg/-/pipelines/601212
>   * flatpak fails because code requires an unreleased ECM
>
>
> kpat - NEW
>  * https://invent.kde.org/games/kpat/-/pipelines/601213
>   * flatpak fails because code requires an unreleased ECM
>
>
> ksudoku - NEW
>  * https://invent.kde.org/games/ksudoku/-/pipelines/601215
>   * flatpak fails because code requires an unreleased ECM
>
>
> kubrick - NEW
>  * https://invent.kde.org/games/kubrick/-/pipelines/601216
>   * flatpak fails because code requires an unreleased ECM
>
>
> palapeli - NEW
>  * https://invent.kde.org/games/palapeli/-/pipelines/601217
>   * flatpak fails because code requires an unreleased ECM
>

All of the Games Flatpak failures are caused by
https://invent.kde.org/games/libkdegames/-/commit/023d1a7b173f9d28453a0268e91ad1ccb47054b9
I intend to revert that commit in 24 hours unless a suitable explaination
can be provided as to why 6.0.0 is actually required.

All that commit has done is cause unnecessary breakage as I can't see
commits before or after it that justify that bump.

The icon-not-found failures all appear to be due to something in Flatpak or
Appstream, so one of the developers from those respective software stacks
needs to take a look given nothing on our side changed.
The price of using Fedora (who upgrades things in stable distros far too
aggressively) for the flatpak-builder image on our CI system (I should
probably swap it out for a more stable / normal distribution...)


>
>
> Cheers,
>   Albert
>

Cheers,
Ben

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

[Ben Cooksley]

On Thu, Feb 8, 2024 at 7:17 AM Friedrich W. H. Kossebau 
wrote:

> Am Mittwoch, 7. Februar 2024, 11:48:57 CET schrieb Ben Cooksley:
> > All of the Games Flatpak failures are caused by
> >
> https://invent.kde.org/games/libkdegames/-/commit/023d1a7b173f9d28453a0268e9
> > 1ad1ccb47054b9 I intend to revert that commit in 24 hours unless a
> suitable
> > explaination can be provided as to why 6.0.0 is actually required.
> >
> > All that commit has done is cause unnecessary breakage as I can't see
> > commits before or after it that justify that bump.
>
> The purpose of the commits (to libkdegames & libkmahjongg, actually
> planned to
> do for all of kdegames repos for consistency) has been to test that things
> still build  everywhere when the major version in the min required KF
> version
> is changed (5.x to 6.x).
> As such major version number change has been the cause for issues in the
> past,
> as some logic relies on that number sometimes.
> So it felt better also tested with KF6 now before the 6.0.0 release
> (compare
> e.g. the struggles Plasma has had with its major version number-based
> logic
> recently).
>
> And while those commits are the trigger, the cause is the design flaw of
> the
> flatpak jobs on "CI", which now exclude KF from CI & CD on the development
> branches, restrict the use of KF API to released versions.
>
> To get things rolling again for now, I have reverted the two commits now,
> removing the trigger again.
>
> I hope people find a solution to that challenge
> they created here though, because this seems a bit the tail (packaging/
> delivery) wagging with the body (development).
>
> If things break somewhere over the major version number in the dep
> version, I
> can say I tried ;)
>

It's more a reflection of how Flatpak works where applications are built on
top of a runtime.

In our case, to avoid every single application needing to build every
single Framework (and wasting copious amounts of disk space not to mention
build CPU time in the process) we place Qt and KDE Frameworks in a runtime
so they can be shared.
For those curious as to how long it takes to build this runtime (excluding
QtWebEngine) see
https://invent.kde.org/packaging/flatpak-kde-runtime/-/jobs/1561108 - yes,
it takes 2 hours on one of our CI nodes to build. Not something that is
practical to build every time you build an application.

Craft also has a similar issue as by default it provides the latest
released version of dependencies unless that is otherwise explicitly
overridden. Using that override though that means it has to build the
dependencies you've overridden every single time it performs a build -
which is not an efficient use of resources. As such it should be used
sparingly, if at all, and only if absolutely needed.

In general the expectation is that KDE applications (which is what all
these continuous delivery pipelines are aimed at) aim to build as a minimum
requirement against the latest released versions of things not in their
release unit (such as Frameworks).
This also makes it easier for new contributors to "jump in" as they can use
the development packages shipped by their distribution rather than needing
to build the world first (which is going to put a new contributor off).

This is in line with the precedent set over the entire lifetime of our Qt 5
based releases, where Frameworks, Release Service and independently
released applications all had independent release schedules and version
schemes.

I appreciate that major version bumps can cause all sorts of breakage
though, i'm expecting some degree of breakage no matter how much we
pre-test.


>
> Cheers
> Friedrich
>
>
Cheers,
Ben

Re: Retirement of Binary Factory

[Ben Cooksley]

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

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

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


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

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

[Ben Cooksley]

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

> On Tuesday, 20 February 2024 22:30:56 CET, Albert Astals Cid wrote:
> > Please work on fixing them, otherwise i will remove the failing CI jobs
> on
> > their 4th failing week, it is very important that CI is passing
> > for multiple
> > reasons.
> >
> > Good News: 11 failing repositories from previous report got fixed
> >
> > Bad news: 3 repositories are still failing and 6 new repositories
> started
> > failing
>
> [...]
>
> > kmag - 2nd week
> >  * https://invent.kde.org/accessibility/kmag/-/pipelines/611893
> >   * flatpak fails in icon-not-found
>
> Ah, forgot to cherry-pick to release/24.02, but did that now.
>
> > klickety - 1st week
> >  * https://invent.kde.org/games/klickety/-/pipelines/611894
> >   * appstream test fails in FreeBSD
>
> This needs
>
> https://github.com/ximion/appstream/commit/d3085b7d1492766f5d7bb5de210c2b11c2e1ead9
> added to FreeBSD's appstream package  (or a new appstream release).
>

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

Cheers,
Ben

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

[Ben Cooksley]

On Wed, Feb 21, 2024 at 12:01 PM Albert Astals Cid  wrote:

> Please work on fixing them, otherwise i will remove the failing CI jobs on
> their 4th failing week, it is very important that CI is passing for
> multiple
> reasons.
>
> VERY BAD NEWS:
>  * Cantor made it to its 4th week with FreeBSD tests failing
>   * I have disabled them
> *
> https://invent.kde.org/education/cantor/-/commit/0f94f381bda4d8f7f52a432d0a846c2ca6bee1e8
>
> Good news: 8 repositories got fixed
>
> Bad news: 2 repo still failing and 5 new this week
>
> ark - 3rd week
>  * https://invent.kde.org/utilities/ark/-/pipelines/611869
>   * tests fail on FreeBSD
>

Wonder if the tests properly handle umask being set?


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

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


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

Fixed now by the FreeBSD image rebuild.


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

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


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

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


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

Cheers,
Ben

Re: Post-MegaRelease projects

[Ben Cooksley]

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

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

This unfortunately will not be easy to solve.

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

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

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

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

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

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

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

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

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


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

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

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

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


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

Hopefully 

Re: Post-MegaRelease projects

[Ben Cooksley]

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

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

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

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

Cheers,
Ben

Re: Post-MegaRelease projects

[Ben Cooksley]

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

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

Re: Post-MegaRelease projects

[Ben Cooksley]

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

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

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


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

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

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


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

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

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

Cheers,
Ben

Re: Post-MegaRelease projects

[Ben Cooksley]

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

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

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

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


>
> Plus,

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

[Ben Cooksley]

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

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

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


>
> /Sune
>
>
Cheers,
Ben

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

[Ben Cooksley]

On Wed, Mar 6, 2024 at 1:22 PM Albert Astals Cid  wrote:

> Please work on fixing them, otherwise i will remove the failing CI jobs on
> their 4th failing week, it is very important that CI is passing for
> multiple
> reasons.
>
> Good News: 7 failing repositories from previous report got fixed
>
> Bad news: 3 repositories are still failing and 6 new repositories started
> failing
>
>
> cantor - 3rd week
>  * https://invent.kde.org/education/cantor/-/pipelines/622239
>   * FreeBSD tests fail
>
>
> kimap - 2nd week
>  * https://invent.kde.org/pim/kimap/-/pipelines/622338
>   * testsession fails on FreeBSD
>
>
> neochat - 2nd week
>  * https://invent.kde.org/network/neochat/-/pipelines/622783
>   * craft builds fail
>
>
> kwave - 1st week
>  * https://invent.kde.org/multimedia/kwave/-/pipelines/622278
>   * Linux build fails, complains that neither rsvg nor convert are
> installed
>

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

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


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

Fix from master has now been cherry picked.


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


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


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


Should be fixed now along with master.


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

Cheers,
Ben

Linking to Gitlab CD build results

[Ben Cooksley]

Hi all,

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

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

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

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

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

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

Thanks,
Ben

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

[Ben Cooksley]

On Wed, Mar 13, 2024 at 12:34 PM Albert Astals Cid  wrote:

> Please work on fixing them, otherwise i will remove the failing CI jobs on
> their 4th failing week, it is very important that CI is passing for
> multiple
> reasons.
>
>
> VERY BAD NEWS:
>  * Cantor made it to its 4th week with FreeBSD tests failing
>   * I have disabled them
> *
> https://invent.kde.org/education/cantor/-/commit/5b2a8285e2f6ecac28f4ae07c602b9b8f8c7f7fa
>
> Good News: 6 failing repositories from previous report got fixed
>
> Bad news: 2 repositories are still failing and 2 new repositories started
> failing
>
>
> kimap - 3rd week
>  * https://invent.kde.org/pim/kimap/-/pipelines/628890
>   * testsession fails on FreeBSD
>
>
> neochat - 3rd week
>  * https://invent.kde.org/network/neochat/-/pipelines/628898
>   * craft build fails
>
>
> kdenlive - NEW
>  * https://invent.kde.org/multimedia/kdenlive/-/pipelines/628930
>   * Qt6 code fails to compile
>
>
> akregator - NEW
>  * https://invent.kde.org/pim/akregator/-/pipelines/628861
>   * appstreamtest fails


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


>
>
>
>
> Cheers,
>   Albert
>

Cheers,
Ben

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

[Ben Cooksley]

On Wed, Mar 13, 2024 at 12:12 PM Albert Astals Cid  wrote:

> Please work on fixing them, otherwise i will remove the failing CI jobs on
> their 4th failing week, it is very important that CI is passing for
> multiple
> reasons.
>
> Good news: 6 repositories got fixed
>
> Bad news: 2 repository still failing and 7 new repositories failing this
> week
>
>
> filelight - 2nd week
>  * https://invent.kde.org/utilities/filelight/-/pipelines/628855
>   * craft fails
>
>
> klickety - 2nd week
>  * https://invent.kde.org/games/klickety/-/pipelines/628858
>   * appstreamtest fails


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

Anyway, this is fixed now.


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


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


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

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


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


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

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


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

Re: AppStream Metadata with our releases

[Ben Cooksley]

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

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

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

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


>
> Regards,
> Volker


Cheers,
Ben

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 projects with failing CI (release/24.02) (2 April 2024)

[Ben Cooksley]

On Wed, Apr 3, 2024 at 11:41 AM Albert Astals Cid  wrote:

> Please work on fixing them, otherwise i will remove the failing CI jobs on
> their 4th failing week, it is very important that CI is passing for
> multiple
> reasons.
>
> Good news: 1 repository was fixed
>
> Bad news: 2 repositories are still failing and 1 repository has started
> failing
>
> kirigami-gallery - 2nd week
>  * https://invent.kde.org/sdk/kirigami-gallery/-/pipelines/650570
>   * Android build fails
>* Similar problem to the one in kirigami being discussed in the
> frameworks
> mailing list
>

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


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

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

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


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

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


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

Re: Should we stop distributing source tarballs?

[Ben Cooksley]

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

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

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

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

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


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

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


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

Re: Should we stop distributing source tarballs?

[Ben Cooksley]

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

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

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


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

This is really the key issue at hand.

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

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

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

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

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

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


>
> Regards,
> Heiko
>

Cheers,
Ben

Re: Should we stop distributing source tarballs?

[Ben Cooksley]

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

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

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

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


>
> Cheers,
>   Johannes


Cheers,
Ben

Re: Should we stop distributing source tarballs?

[Ben Cooksley]

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

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

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

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

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

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


>
> Best regards
>
> Marc


Cheers,
Ben

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

[Ben Cooksley]

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

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

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

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


>
> Regards,
> Ingo


Cheers,
Ben

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

[Ben Cooksley]

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

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

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

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

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

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

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

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

[Ben Cooksley]

On Wed, Apr 10, 2024 at 9:26 AM Albert Astals Cid  wrote:

> Please work on fixing them, otherwise i will remove the failing CI jobs on
> their 4th failing week, it is very important that CI is passing for
> multiple
> reasons.
>
> Good news: 3 repositories got fixed
>
> Bad news: 2 repositories still failing and new 5 repositories failing this
> week
>
>
> umbrello - 3rd week
>  * https://invent.kde.org/sdk/umbrello/-/pipelines/657654
>   * craft_windows_qt515_x86_64 fails
>
>
> kirigami-gallery - 3rd week
>  * https://invent.kde.org/sdk/kirigami-gallery/-/pipelines/657659
>   * Android build fails


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


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

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

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


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

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


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

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

[Ben Cooksley]

On Wed, Apr 10, 2024 at 9:33 AM Albert Astals Cid  wrote:

> Please work on fixing them, otherwise i will remove the failing CI jobs on
> their 4th failing week, it is very important that CI is passing for
> multiple
> reasons.
>
> Good news: 1 repository was fixed
>
> Bad news: 2 repositories are still failing and 6 repositories has started
> failing
>
> kirigami-gallery - 3rd week
>  * https://invent.kde.org/sdk/kirigami-gallery/-/pipelines/657676
>   * Android build fails
>
>
> umbrello - 3rd week
>  * https://invent.kde.org/sdk/umbrello/-/pipelines/657665
>   * craft_windows_qt515_x86_64 fails
>
>
> krdc - NEW
>  * https://invent.kde.org/network/krdc/-/pipelines/657666
>   * Linux builds fail because of missing dependencies
>

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


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

Cheers,
Ben

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

[Ben Cooksley]

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

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

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


>
> Regards
> Ralf
>
>
Cheers,
Ben

Re: Upcoming changes to CI system

[Ben Cooksley]

On Mon, Oct 28, 2013 at 12:46 AM, Allen Winter  wrote:

> On Sunday, October 27, 2013 09:32:59 PM Ben Cooksley wrote:
> > Hi all,
> >
> > In order to improve the maintainability and cleanliness of the "shared
> > dependencies" the way they will be handled on the CI system will be
> > changing.
> >
> > The nature of this change is that all projects which need a "shared
> > dependency" will now need to declare a dependency against it in the
> > appropriate file in the CI script configuration.
> >
> > A shared dependency is essentially a non-KDE project:
> > a) Where distribution packages are too old (like CMake)
> > b) projects which depend on Qt (and therefore cannot be installed system
> > wide)
> >
> > A list of shared dependencies can be seen at
> > http://build.kde.org/view/External_Deps/
> >
> > I have the following known shared dependencies at the moment:
> > kde/*: shared/kdesupport-svn
> > kde/kde-workspace: shared/libdbusmenu-qt
> > kde/kdepim: shared/grantlee
> > kde/kdepim-runtime: shared/libkolab[libkolab-0.4]
> > kde/kdegraphics/okular: shared/poppler
> > kde/kdebindings/pykde4: shared/pyqt4
> > calligra: shared/vc
> > extragear/libs/libkface: shared/opencv
> > extragear/multimedia/amarok: shared/gmock
> > extragear/network/telepathy/*: shared/telepathy-qt4
> >
> > If anything needs to be added to the list, please let me know. Of
> > particular interest are dependencies on Grantlee, QOAuth, QJSON, Qt
> > GStreamer, Qt Mobility, Qwt and Shared Desktop Ontologies.
> >
> > Both libindi and libssh are going to be shifted to distribution packages.
> >
>
> kdegraphics/libs libkdcraw: shared/libraw
>

libraw is provided as a system-wide package - so it doesn't need to be
mentioned.

Thanks,
Ben

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Upcoming changes to CI system

[Ben Cooksley]

On Mon, Oct 28, 2013 at 1:59 AM, Scott Kitterman  wrote:

>
>
> Ben Cooksley  wrote:
> >Hi all,
> >
> >In order to improve the maintainability and cleanliness of the "shared
> >dependencies" the way they will be handled on the CI system will be
> >changing.
> >
> >The nature of this change is that all projects which need a "shared
> >dependency" will now need to declare a dependency against it in the
> >appropriate file in the CI script configuration.
> >
> >A shared dependency is essentially a non-KDE project:
> >a) Where distribution packages are too old (like CMake)
> >b) projects which depend on Qt (and therefore cannot be installed
> >system
> >wide)
> >
> >A list of shared dependencies can be seen at
> >http://build.kde.org/view/External_Deps/
> >
> >I have the following known shared dependencies at the moment:
> ...
> >kde/kdebindings/pykde4: shared/pyqt4
>
> For pykde4 there is also sip:
> http://www.riverbankcomputing.com/software/sip


SIP is provided by a system-wide package in this case - so we don't need to
mention it (as it isn't a shared dependency.


>
>
> ...
>
> Scott K
>

Thanks,
Ben


>
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> unsubscribe <<
>

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Upcoming changes to CI system

[Ben Cooksley]

On Sun, Oct 27, 2013 at 9:43 PM, Peter Grasch  wrote:

> Hi Ben,
>
> On 10/27/2013 05:32 PM, Ben Cooksley wrote:
> > A shared dependency is essentially a non-KDE project:
> > a) Where distribution packages are too old (like CMake)
> > b) projects which depend on Qt (and therefore cannot be installed system
> > wide)
> >
> > A list of shared dependencies can be seen
> > at http://build.kde.org/view/External_Deps/
> >
> > I have the following known shared dependencies at the moment:
> > [...]
> extragear/accessibility/simon: shared/opencv, shared/qwt
>

Thanks Peter, i've added that to my list.


>
> Thanks.
>
> Best regards,
> Peter
>

Thanks,
Ben

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Repository rename and consequences

[Ben Cooksley]

Hello all,

Sysadmin has received a request to rename the repository "kwallet"
(currently located at kde/kdeutils) to "kwalletmanager" in order to
free this name up.

Once that has been completed, the repository "kwallet-framework"
(located at frameworks/) will be renamed to "kwallet".

This will have the affect, and will appear as, a force push to the
"kwallet" repository to all Git clients.

Once the procedure has been completed, automated build scripts such as
kdesrc-build should automatically clone the repositories under their
new names - however custom scripts and procedures will need to be
adjusted by hand.

If anyone has any objections, please let us know. This change will be
made in 48 hours.

Thanks,
Ben Cooksley
KDE Sysadmin

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Repository rename and consequences

[Ben Cooksley]

On Sat, Feb 8, 2014 at 10:58 AM, Ben Cooksley  wrote:
> Hello all,
>
> Sysadmin has received a request to rename the repository "kwallet"
> (currently located at kde/kdeutils) to "kwalletmanager" in order to
> free this name up.
>
> Once that has been completed, the repository "kwallet-framework"
> (located at frameworks/) will be renamed to "kwallet".
>
> This will have the affect, and will appear as, a force push to the
> "kwallet" repository to all Git clients.
>
> Once the procedure has been completed, automated build scripts such as
> kdesrc-build should automatically clone the repositories under their
> new names - however custom scripts and procedures will need to be
> adjusted by hand.
>
> If anyone has any objections, please let us know. This change will be
> made in 48 hours.

Due to the lack of objections or other commentary, I have now
performed this change as originally requested.

The repository "kwallet", referring to kde/kdeutils/kwallet has now
been renamed to "kwalletmanager".
The repository "kwallet-framework" referring to
frameworks/kwallet-framework has now been renamed to "kwallet".

>
> Thanks,
> Ben Cooksley
> KDE Sysadmin

Thanks,
Ben Cooksley
KDE Sysadmin

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Remove tags from origin

[Ben Cooksley]

On Tue, Feb 11, 2014 at 10:50 PM, Shubham Chaudhary
 wrote:
>>Hi all,
>
> Hi Elvis,
>
>>remote: FATAL: D refs/tags/0.1.0 >kronometer elvisangelaccio DENIED by 
>>>fallthru
>>remote: error: hook declined to update >refs/tags/0.1.0
>>To g...@git.kde.org:kronometer
>> ! [remote rejected] 0.1.0 (hook declined)
>>error: failed to push some refs to >'g...@git.kde.org:kronometer'
>>
>>So, am I allowed to remove remote tags? If >yes, what is the right git 
>>command?
>
> AFAIK you need special RW+ permissions to remove references in any repo. The 
> default permission for developer account I think is RW.

To remove tags, you need RWCD permissions. Nobody has + permissions
except temporarily where needed to repair a repository, as that
permits force pushes.

The only holders of RWCD permissions are the KDE Project Manager's for
a given repository. It seems when the Kronometer repository was
initially created your Identity username must have been typo'ed, as
that wasn't granted to you. I have now fixed that.

>
>
> --
>
> Regards,
> Shubham Chaudhary - http://about.me/shubhamchaudhary
> http://www.shubhamchaudhary.in
> Sent from BlackBerry®

Thanks,
Ben Cooksley
KDE Sysadmin

>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Re: Keyboard shortcut enhancement.

[Ben Cooksley]

On Fri, Feb 14, 2014 at 7:39 PM, Martin Gräßlin  wrote:
> On Friday 14 February 2014 04:19:04 Michael Jansen wrote:
>> I am btw not really sure khotkeys should still be part of kde5. its broken,
>> never really reached kde4 anyway and both lubos and i don't work on it
>> anymore. And it failed to attract anyone else.
>
> Thanks for letting us know. I ported it over to frameworks but to be honest
> had no idea how to properly test it ;-) So if you think it should be killed,
> maybe just do the git rm.

Please note that certain parts of KHotkeys functionality, particularly
that related to executing an arbitrary command have been particularly
useful for integrating non-KDE applications which don't support global
shortcuts, as well as for working around problems in the global
shortcut support provided by some applications.

Given it's status, perhaps someone might want to advertise that we're
looking for a rewrite / new maintainer for the KF5 iteration?

>
> Cheers
> Martin
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
>

Thanks,
Ben

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: KActivities/master is now KF5/Qt5

[Ben Cooksley]

On Fri, Feb 28, 2014 at 9:50 PM, Ivan Čukić  wrote:
> Hi all,
>
> Now that the 4.13 has been branched out, the master branch of KActivities is
> for Qt5/KF5 development.
>
> I have updated the branch name in kf5-frameworks-build-include (I guess
> David had something else in mind, so I'm CC-ing him even though he is a
> member of every list I'm sending this to :) )
>
> The only things left to do are (I'm looking at Ben or Albert with hope in my
> eyes):
>  - update kde:kde-build-metadata - I don't dare to do this myself. It should
> use KDE/4.13 branch for Qt4, and master for Qt5.
>  - blacklist and delete the frameworks branch

The metadata has now been sorted.

>
> Cheerio,
> Ivan

Regards,
Ben

>
> --
> While you were hanging yourself on someone else's words
> Dying to believe in what you heard
> I was staring straight into the shining sun

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: What to test for 4.13?

[Ben Cooksley]

On Mon, Mar 10, 2014 at 7:06 PM, Ian Wadham  wrote:
>
> On 09/03/2014, at 8:23 PM, Kevin Krammer wrote:
>
>> Hi Ian,
>>
>> On Sunday, 2014-03-09, 17:33:12, Ian Wadham wrote:
>>> Hi Kevin and Frank,
>>>
>>> On 08/03/2014, at 11:02 PM, Kevin Krammer wrote:
 On Saturday, 2014-03-08, 21:47:07, Ian Wadham wrote:
> On 08/03/2014, at 6:43 PM, Frank Reininghaus wrote:
>> 2014-03-08 4:38 GMT+01:00 Ian Wadham:
>>> While we are on the topic of testing, how much testing is done of
>>> KDE's cross-platform and cross-desktop implementations?
>>
>> Unless the people who prepare the Mac packages test them, the only
>> testing is done by you and by other users,
>
> So what I am hearing, in answer to my question, is "No testing by the KDE
> development team".

 I think this would only be the case if the two groups of people, KDE
 Developers and KDE-on-Mac packagers/users, were non-overlapping sets.
>>>
>>> I think they probably are non-overlapping sets.  There *is* a KDE Mac
>>> mailing list, but I receive only a few posts per year from it, as compared
>>> with several a day from Macports.
>>
>> Ah, interesting.
>> This makes it very different from all other platforms (various Linux
>> distributions, BSD, Windows, mobile platforms), where some of the packagers
>> are also KDE developers.
>
> Macports grew out of something Apple did in the early days, mainly directed
> at getting any kind of free open-source software onto Apple Mac.  There are
> also Fink and Homebrew doing similar jobs.
>
> A lot of the emphasis is on GNU utilities and languages such as Perl, TCL
> and Python, plus some Science packages and Fortran, used by real scientists,
> free database packages (mysql, mariadb, sqlite, etc.).
>
> The Macports have fantastic Unix/BSD and sysadmin skills, but not much
> knowledge of KDE.  The KDE porting team does a good job and are currently
> at KDE 4.12.2, but they make not much attempt to adapt or convert KDE to run
> smoothly in the Apple OS X environment.  One guy goes a bit deeper, with
> KMyMoney4, and is in touch with the developers, I think.  I help him too,
> when I can.  Both of us rely on KMM4 to run our finances ... ;-)
>
 That might of course be true, but also a bit uncommon. Packaging efforts
 for all other platforms is at least to some extend handled by people who
 are either users of the packaged software or KDE developers using the
 respective platform.
>>>
>>> Part of the problem may be that, until recently, it has been difficult for
>>> a KDE developer to just buy a MacBook Pro and set up a dual-boot or
>>> virtualised Linux system on it.  But now it is quite easy ... :-)  I aim to
>>> have a go, once I have Palapeli for KDE 4.13 put to bed.
>>
>> The main part of the problem, i.e. Apple at least officially requring special
>> hardware, still remains.
>> I am not sure it is feasible to assume anyone would buy a second computer 
>> just
>> to satisfy some hardware vendor's lock-in phantasies.
>
> I think your prejudices are showing, Kevin ... :-)  Actually Apple Mac
> hardware is bog-standard Intel underneath and OS X is BSD UNIX
> underneath. When I am doing KDE development, I might as well be
> sitting using a Konsole or XTerm window.  The problem up till now
> has been EFI booting, but there is now a package called "rEFIt" that
> can set up partitions and the boot area to boot whatever you like.

Whilst there is nothing particularly special about Mac hardware now,
one is only allowed by the Mac OS X licensing to run it on Apple
hardware.

It is therefore impossible for KDE to provide Continuous Integration
support without Apple hardware.
For the same reasons, it isn't possible for individual KDE developers
to test their work.

As far as I know, one cannot virtualise Mac OS X, or if one can, it
must still be done on Apple hardware.

>
> I am old enough to remember why Apple went the way it did in 1982
> with the Lisa and Mac.  It was to keep control over configuration and
> minimise support problems.  IBM with their PC, by contrast, let the
> genie out of the jar and look where Microsoft and even Linux users
> are today ...
>
> At an educational group I belong to there is a monthly PC Users Group,
> all these people my age struggling with MS Windows, security, viruses,
> malware, how to set up a network, etc.  There is no real need for an
> Apple Users Group ...
>
>> However, those who own Apple hardware seem to either not use OSX or not use
>> KDE applications on OSX, otherwise there would be an overlap in the
>> users/developers group.
>
> Users yes ... developers no.  I think I am the only KDE developer on Apple
> and that is only for applications --- and games at that.  I am not a "core"
> developer.  I might be able to do that stuff.  I used to before I retired from
> the workforce, but now I just like to program for fun ... :-)
>
>> Do you know if the Mac packaging group is just building the software or if
>> they also run 

Re: Running KDE apps on Apple OS X

[Ben Cooksley]

On Thu, Mar 13, 2014 at 7:44 AM, John Layt  wrote:
> Some random/long thoughts on KDE on Mac, seeing as I'm a sometimes Qt
> Mac developer and a KDE-on-Mac user, subscribed to the KDE Mac list,
> was the guy who got the outdated website taken down as it was
> confusing people, and got a bit burnt-out repeatedly trying to get Mac
> people to engage with KDE and each other.

Hi John,

>
> I use Kate extensively on Mac, and Dolphin when Finder is too
> brain-dead.  What frustrates me most is having to rebuild Macports all
> the time, it takes forever and is not a good way to win over normal
> users.  It can also screw with my Qt test builds.  We need a "normal"
> install method on Mac for normal end-users and neither Macports or
> Homebrew or Fink provide this.  They're hacker tools still, even after
> all these years, not end-user tools.  Other projects like LibreOffice
> have standalone Mac binary installers that they produce themselves (as
> does Marble already) as Macports/etc are not a viable distribution
> option for them.  While the Windows Installer is not a great UX for
> normal users, it's beats the options on Mac hands down, I wish we had
> such an option on Mac.  Taking on building our code on Mac for
> ourselves can only improve the situation, even if just by freeing the
> Macports/Homebrew/Fink guys up a little to work on integration and
> binary distribution.
>
> Macports: they try hard to keep up with releases, and its the only
> reliable semi-easy way to install KDE on Mac, but we keep breaking
> things for them, and I'm not sure I've seen many efforts to push
> patches upstream.  They were not connected in to the KDE community at
> all, in spite of my trying to encourage them in the distant past to
> join the kde-mac list to coordinate things and ask us questions when
> we break stuff, and for us to ask questions when we need to add Mac
> support.  Which is why it's so good to see Ian pushing for this, we
> need people who know both communities to build that link.
>
> Homebrew looked promising when I looked for alternatives to Macports,
> especially with prominent ex-KDE people running it, but the problem
> there was no official support, you can't install KDE from the main
> repo.  Last time I tried I couldn't figure out how to use any of the
> forks that did.  Good news here is that there is now an effort to
> unite all the forks and make an official repo (see
> https://github.com/adymo/homebrew-kde/issues/11), with well-know KDE
> peeps adymo and haraldf involved and currently pushing patches
> upstream to fix Mac build issues.  But nary a peep on the kde-mac
> list, so others may not know what's going on.
>
> Fink:  No idea on the current status, last time I tried years back
> they were well out-of-date so I stuck with Macports.
>
> And there's the problem with KDE on Mac in a nutshell: three different
> build technologies, designed for hackers, with little coordination
> between them or us.  So I beg you all: SUBSCRIBE TO THE KDE-MAC LIST
> AND CO-ORDINATE THERE!  COMMUNICATE!  I want our Mac group to revive,
> and if we work together to solve problems and maintain the upstream
> KDE build in KDE with CI to keep them building then it's a lot less
> work downstream!  We need to build the same relationship with the Mac
> builders as we have with the Linux disto packagers, we build and
> maintain the code, they package and distribute.
>
> What to do at the KDE end?
>
> We have a wiki at http://community.kde.org/Mac that we need to keep
> updated as things change, as that is where mac.kde.org redirects.  We
> also have the forum at http://forum.kde.org/viewforum.php?f=60, but
> for devs please use the list at
> https://mail.kde.org/mailman/listinfo/kde-mac.  I can't emphasise
> enough: if everyone who's doing stuff with KDE-on-Mac were to talk to
> each other there, there would be a lot less work needed!
>
> Qt5/KF5 may improve things, but we still need to build infrastructure
> to support Mac.
>
> We need CI Mac builds to test KF5 stuff and prevent Linuxisms and
> build breakers from creeping in over time, e.g. to ensure the creation
> of Mac Frameworks (a special type of library) works as you need to
> follow strict include rules that Linux or Windows don't need.  It's
> part of our "KF5 everywhere Qt is" strategy.  Advanced Mac platform
> integration will also need CI builds to check they don't get broken by
> Linux-focussed devs :-)

In terms of the bare minimum requirements of the CI system itself (not
taking into account anything being built) the following is needed.
I'm assuming it is all available?

- Java (either Oracle or IcedTea)
- Python (with lxml support)
- RSync
- SSH
- Git
- Subversion
- Bazaar

The code to initiate a testing environment will probably also need
customisation - Xvfb and Openbox are obviously not necessary or usable
on Mac (if they're even available)

>
> We need remote gui or shell access to Macs to allow selected devs to
> do test builds of their apps, or at 

Re: Running KDE apps on Apple OS X

[Ben Cooksley]

On Fri, Mar 14, 2014 at 8:56 PM, Ian Wadham  wrote:
> Hi Ben,

Hi Ian,

>
> On 13/03/2014, at 7:15 AM, Ben Cooksley wrote:
>> On Thu, Mar 13, 2014 at 7:44 AM, John Layt  wrote:
>>> What to do at the KDE end?
>>>
>>> We have a wiki at http://community.kde.org/Mac that we need to keep
>>> updated as things change, as that is where mac.kde.org redirects.  We
>>> also have the forum at http://forum.kde.org/viewforum.php?f=60, but
>>> for devs please use the list at
>>> https://mail.kde.org/mailman/listinfo/kde-mac.  I can't emphasise
>>> enough: if everyone who's doing stuff with KDE-on-Mac were to talk to
>>> each other there, there would be a lot less work needed!
>>>
>>> Qt5/KF5 may improve things, but we still need to build infrastructure
>>> to support Mac.
>>>
>>> We need CI Mac builds to test KF5 stuff and prevent Linuxisms and
>>> build breakers from creeping in over time, e.g. to ensure the creation
>>> of Mac Frameworks (a special type of library) works as you need to
>>> follow strict include rules that Linux or Windows don't need.  It's
>>> part of our "KF5 everywhere Qt is" strategy.  Advanced Mac platform
>>> integration will also need CI builds to check they don't get broken by
>>> Linux-focussed devs :-)
>>
>> In terms of the bare minimum requirements of the CI system itself (not
>> taking into account anything being built) the following is needed.
>> I'm assuming it is all available?
>>
>> - Java (either Oracle or IcedTea)
>> - Python (with lxml support)
>> - RSync
>> - SSH
>> - Git
>> - Subversion
>> - Bazaar
>
> I think all of those are available.  Attached is a summary of search
> results for "bazaar" and "lxml", on the latest Macports index.  More
> detail on any of those packages can be provided by "port info" if
>  you need it.  I have certainly used git and Subversion on
> Mac OS X to maintain and check in my code.  I am also using
> Java and mysql to run a business administration app that was
> developed by a friend of mine on Windows.

Okay, excellent.

>
>> Please note that if we do purchase such systems then we need to find a
>> place to host them - and someone to look after them should they need
>> to be moved or require hardware maintenance (disk failures, etc).
>> Ideally we would hire them from a DC which offers that.
>
> I do not think they would need much hosting. Each Mac Mini is only
> about the size of 3 or 4 CD cases.  The network connections would be
> another matter.  Apple support at the Apple Store for Macs, MacBooks,
> iPads and iPhones is excellent, and free.  I am amazed how much
> time they are prepared to spend with my wife and me without any
> complaining ...  For a Mac Mini you might need to hook into the
> "Genius Bar" guys though ... :-)

We'll await the results of the Macports collaboration thread before
continuing further.
Ideally though the datacenter operator would look after the hardware
aspect - this has worked very well for us with Hetzner and our Linux
systems.

>
> You might also like to look at the new Mac Pro, which is more
> expensive but extremely powerful (Intel Xeon).  It is cylindrical with
> a hole in the top.  You'd just have to be careful nobody pours their
> coffee into it ... :-)
>
> Cheers, Ian W.

Regards,
Ben

>
>
>
>
>
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
>

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Problems found by the CI system

[Ben Cooksley]

Hi all,

It seems lately that people have been breaking builds and not fixing
the results, and some builds are extremely unreliable. It would be
appreciated if these could be fixed.

Frameworks folks, when pushing binary incompatible changes, please
ensure you push them to the frameworks in the correct order, and wait
for builds to complete before moving on to the next one.

I've now fixed, by issuing rebuilds, two recent Binary Compatability
breaches which caused kde-runtime among others to fail to build.

Bindings people, please investigate the failures in smokegen. This
tool is extremely unreliable in the CI environment and has failed many
times previously. It is currently causing smokekde to fail to build,
which in turn blocks perlkde, korundum and kimono.

If you need a backtrace, please let me know. From what I can tell,
this tool is incompatible with a Qt built in debug mode (ie. with
assertions enabled).

Baloo developers, please take a look at the failure in this log -
http://build.kde.org/view/FAILED/job/baloo_stable/80/console. When
referencing projects outside your own, it is imperative the correct
include statements are used in the CMake logic.

KDE Workspace devels, please do not attempt to host a framework within
a repository which then uses this framework. This prevents people
without a previous installation of it from being able to build it - an
environment the CI system provides. Packagers will be unable to build
it as well.

Thanks,
Ben

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Problems found by the CI system

[Ben Cooksley]

On Tue, Mar 25, 2014 at 12:37 AM, Vishesh Handa  wrote:
> On Monday, March 24, 2014 06:59:24 PM Ben Cooksley wrote:
>>
>> Baloo developers, please take a look at the failure in this log -
>> http://build.kde.org/view/FAILED/job/baloo_stable/80/console. When
>> referencing projects outside your own, it is imperative the correct
>> include statements are used in the CMake logic.
>>
>
> I've pushed a commit. That should hopefully fix it.

Unfortunately it seems the build still fails -
http://build.kde.org/view/FAILED/job/baloo_stable/81/console
Please note that this is the stable build (KDE/4.13 branch).

Thanks for fixing the master branch though - all it's tests are now passing.

>
> Could you perhaps add some hook to email me about these failures? We don't
> have a dedicated mailing list for Baloo and I'm not sure if notifying kde-
> devel would be a good idea.

I've now configured it to send you emails for both the Baloo master
and stable builds.

>
> --
> Vishesh Handa

Thanks,
Ben

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

CI System Documentation

[Ben Cooksley]

Hi everyone,

As it seems very few people understand the process by which the CI
system is configured, i've written some rather lengthy documentation
on the process it follows and the configuration options available at
each stage.

This can be found in the documentation/ folder of
websites/build-kde-org, production branch.

It would be appreciated if those interested would please take a look
at it and comment on anything they see as absent / confusing.

Thanks,
Ben

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Running KDE apps on Apple OS X

[Ben Cooksley]

On Sun, Apr 13, 2014 at 2:31 AM,   wrote:
> Hi Ben,

Hi Marko,

>
> On 15 Mar 2014, at 12:07 , Ben Cooksley  wrote:
>> We'll await the results of the Macports collaboration thread before
>> continuing further.
>
> in the meantime we have proceeded somewhat regarding our efforts to collect 
> some information about current problems of KDE software on MacPorts.
> For that purpose we have eventually created a dedicated wiki page during the 
> last few days [1].
> It also contains a section entitled "Continuous Integration of KDE software".
>
> I guess it is not possible to simply install Jenkins and start building on 
> OSX. :-)
> Well, a while ago I installed Jenkins on my old iMac and found that it 
> actually worked out of the box for makeicns [2], but I have never tried to do 
> anything else with it, since about at the same time the MacPorts buildbots 
> appeared on the scene [3].

Not exactly, however the infrastructure we have for our Linux builds
should be nearly completely portable to OSX without too much trouble
(in theory at least - i've never done any compilation on OSX).

>
> Which prerequisites do you need for your CI system on Linux? Where can I read 
> about that?
> I guess without more information it doesn't make sense to approach the 
> MacPorts developer team regarding their buildbots' setup...

The actual requirements aren't written anywhere, but you might find
the documentation i've written for the CI system to be of some use.
See 
http://quickgit.kde.org/?p=websites%2Fbuild-kde-org.git&a=tree&h=48c561bdfa467b0a09d6591491abc168b63197ce&hb=f2d024f155bed23a9e81b0175e5c7d752d6d8f14&f=documentation

A basic run down of what the CI system needs however:

1) Python 2.x, with json and lxml support (for the scripts which conduct builds)
2) Java (for the Jenkins node agent itself)
3) RSync and SSH (for the transferral of completed builds between nodes)
4) Git, Subversion, Bazaar, wget and GNU Tar (to access source code)
5) GNU Patch (for applying custom patches, used in certain builds)
6) A compiler, usable by CMake, QMake and autotools based build systems
8) GNU Make, Automake, Autoconf (for carrying out the build, and
configuring it in certain rare cases)

We'll need to make adjustments to ensure the system doesn't attempt to
launch Xvfb or a X11 Window Manager, which it currently will do when
executing tests. These should be fairly easy to do however.

To build certain projects, the compiler will need to support C# and a
certain level of C++11 as well. The Mono bindings will not be
buildable if C# support is unavailable.

Under no circumstance should a CI node have Qt installed at the system
level in any form, as this is provided directly by the CI system
itself.

>
> Have a nice weekend!
>
> Greets,
> Marko

Thanks,
Ben

>
>
> [1] https://trac.macports.org/wiki/KDEProblems
> [2] https://bitbucket.org/mkae/makeicns
> [3] https://build.macports.org/builders

Thanks,
Ben

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Mailing list tone

[Ben Cooksley]

Hi everyone,

Due to the current tone of this mailing list I have enabled emergency
moderation for this mailing list.

I urge all involved to please carefully review all the posts that have
been made to the list, consider why others have taken the position
they have and what steps could be taken to improve the situation.

Above all, please respect the Code of Conduct in all further messages
to the list.

Thanks,
Ben Cooksley
KDE Sysadmin

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Help, Baloo source has moved, how do I build KDE 4.13?

[Ben Cooksley]

On Fri, May 23, 2014 at 6:09 PM, Ian Wadham  wrote:
> Hi KDE guys,

Hi Ian,

>
> Using kdesrc-build version 1.16-pre2 to build a KDE software base,
> I find that the Baloo source code has gone missing in the last few
> days.  I am trying to build KDE 4.13 (branch-group stable-qt4, which
> is described by kdesrc-build as "the latest KDE release + bug fixes").
>
> Baloo source used to be in kdelibs.  Now it seems to be in kde-workspace.
>
> Building kde-baseapps calls for baloo-widgets and kfilemetadata to be built
> and that is where my build bombs out, in the CMake phase.
>
> I have been avoiding building kde-workspace up till now,
> because I am trying to build on Apple OS X, which has its own
> desktop environment and its own indexer for that matter.  So
> there should be no need to build either kde-workspace or baloo.
>
> Perhaps I can somehow eliminate the dependency on kfilemetadata
> or baloo-widgets?
>
> I have been trying to do this build for three weeks now and have had
> nearly 50 attempts.  I thought I finally had victory in my grasp until this
> move of Baloo happened.
>
> The build is important because, if I can build a Debug version of KDE 
> libraries,
> utilities and apps, we will have a test platform on which to investigate the
> many KDE software portability problems that exist on Apple OS X, narrow
> down the possible causes and try out solutions.
>
> Also I have a feeling this Baloo move is going to impede our KDE port
> developer's efforts to port KDE SC 4.13 to MacPorts on Apple OS X.
>
> Any ideas on how to build Baloo ... or not build it?

While I can't answer the question on whether Baloo can be avoided for
OS X, I have corrected the issue.

As Baloo and KFileMetadata are dependencies of KDE 4.x series
applications, namely Gwenview, PIM and Dolphin, the change to move
them both to kde/workspace/ from kde/kdelibs/ has now been reverted.

>
> Cheers, Ian W.
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Regards,
Ben Cooksley
KDE Sysadmin

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: reviewboard email

[Ben Cooksley]

On 26 June 2014 22:11, Hugo Pereira Da Costa  wrote:
> On 06/26/2014 12:10 PM, Hugo Pereira Da Costa wrote:
>
> Sorry if it is not the right list.

Hi Hugo,

> Some month ago I have changed email adress because old one
> (h...@oxygen-icons.org) is permanently broken and 'thought' I had made the
> change every where. Seems however that my email (associated to
> hpereiradacosta) is still the old one, so that I missed a couple of review
> requests addressed to me, and then I have no clue where to change this guy.
> Any clue ? (I checked my KDE identity and the email adress provided there is
> the correct +new+ one).

If you access your Identity profile and trigger a change (such as
saving your profile again, even if you don't change anything) does
that cause Reviewboard to update?

It is possible that your Identity email change took place at the time
when the automatic propagation system wasn't 100% working.

>
> Thanks in advance,
>
> Hugo

Thanks,
Ben Cooksley
KDE Sysadmin

>
> ... missed this one, for instance :
> https://git.reviewboard.kde.org/r/118665/
> (but thanks for fixing Aurelien anyway)
>
>
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
>>> <<
>

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Kdenlive repository force pushed

[Ben Cooksley]

Hi all,

Just a notice that the Kdenlive repository has been force pushed as requested.
This affects the "master" branch which has now been set to match the
content of the "next" branch.

The content of the "master" branch is now known as the "movit" branch.

Before pushing to the repository, please ensure your local clone is
properly updated (recloning if you're not sure).

Thanks,
Ben Cooksley
KDE Sysadmin

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Unsolicited email delivered to the mailing list

[Ben Cooksley]

Hi all,

Just to let you know, the delivery of unsolicited email to these
mailing lists recently is in the process of being dealt with. This was
not the result of a fault in Mailman - the identity of a mailing list
member has been impersonated to abuse our lists.

The ultimate originating sender (Nextdoor.com) has been indefinitely
blacklisted from all KDE Sysadmin handled domains as a result (for
both personal and mailing list traffic).

In addition, a complaint has been filed with the whitelisting provider
(ReturnPath) for their email service provider (Mailgun.com) requesting
that the offending behaviour be dealt with appropriately. If
Mailgun.com refuses to implement impersonation prevention, they will
also be subject to being indefinitely blacklisted.

Apologies for any inconvenience this may have caused.

Thanks,
Ben Cooksley
KDE Sysadmin

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Moving polkit-kde-agent-1 to kde/workspace

[Ben Cooksley]

On Sat, Nov 29, 2014 at 4:58 PM, Ian Wadham  wrote:
> Hi David,

Hi Ian,

>
> On 29/11/2014, at 1:19 AM, David Edmundson wrote:
>> Polkit-kde-agent is a small daemon that runs in the user's session bus, and 
>> prompts a user for authentication when a process on the same session 
>> requests polkit authorisation.
>>
>> It is currently in extragear/base, however given it is an essential part of 
>> the workspace in order to use polkit actions I would like to move it to be 
>> part of the Plasma release.
>>
>> This was discussed on plasma-devel with positive reception from active 
>> maintainers, I am asking on core-devel to confirm no-one has any objections 
>> to us making this move.
>
> If you can possibly avoid it, please do not put Polkit-kde-agent in a
> Plasma-only module (as has happened to Dr Konqi).  That is if p-k-a
> is something that might need to run on a platform where Plasma is
> not used, such as Windows or Apple OS X.

polkit-kde-agent is very much part of the desktop session and manages
authentication prompts from Polkit. Windows and OS X have their own
frameworks here, while other desktop environments such as GNOME, Xfce,
etc. would provide their own polkit agents.

Polkit is used to run helpers with additional privileges (usually by
running as root) to perform certain tasks (like changing the system
time).

>
> Cheers, Ian W.

Thanks,
Ben

>
>
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Announcing heaptrack - a Heap Memory Profiler for Linux

[Ben Cooksley]

On Fri, Dec 5, 2014 at 3:10 AM, Milian Wolff  wrote:
> On Wednesday 03 December 2014 01:51:57 Aleix Pol wrote:
>> On Tue, Dec 2, 2014 at 6:59 PM, Milian Wolff  wrote:
>> > Hey all,
>> >
>> > I have just finished writing a lengthy introduction to heaptrack, an
>> > alternative to Massif, see:
>> >
>> > http://milianw.de/blog/heaptrack-a-heap-memory-profiler-for-linux
>> >
>> > I'd like to see more people starting to use it. Any feedback, or even
>> > patches,
>> > is welcome!
>> >
>> > Especially, I'd love to see more people use it on their pet project in
>> > KDE.
>> > Quite often, you'll find useless temporary allocations, overly large
>> > memory
>> > consumption or even significant memory leaks. C++/Qt/KDE code can be
>> > extremely
>> > efficient, but you have to code accordingly. If you have any questions to
>> > the
>> > results you obtain from heaptrack, or how to improve the situation, don't
>> > hesitate to ask me. Please ask on a public mailing list, such that others
>> > can
>> > benefit from the discussion as well.
>> >
>> > Furthermore, I hereby request an official code review. Heaptrack currently
>> > lives in a scratch repository:
>> >
>> > http://quickgit.kde.org/?p=scratch%2Fmwolff%2Fheaptrack.git
>> >
>> > I want to move this to extragear, skipping playground altogether, if
>> > possible.
>>
>> Cool stuff! I'll definitely give it a try!
>>
>> Regarding the move to extragear, you can start requesting the repository to
>> get it in playground and then request the move to kdereview, if you're
>> confident it's pristine. ;)
>
> Can I not skip playground? The review can be done from the scratch repo, and
> admins can then move that to extragear, no?

I'd suggest requesting a repo now - and asking for it to be created in
KDE Review.
You can certainly go from Scratch straight to KDE Review.

>
> Bye
> --
> Milian Wolff
> m...@milianw.de
> http://milianw.de
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Cheers,
Ben

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Compilation time

[Ben Cooksley]

On Mon, Jan 5, 2015 at 11:06 AM, Jan Kundrát  wrote:
> On Sunday, 4 January 2015 19:23:30 CEST, A. Mani wrote:
>>
>> Do we have an approximate chart for relative compilation times for
>> installing kde components/applications from source ?
>
>
> You can take a look at Jenkins' dashboard at [1]. I don't know whether the
> build slaves use something like ccache, though.

The build nodes do use ccache extensively.
The machines also vary quite a bit in terms of their CPU power so
expect wild variations in build times for some projects.

>
> Cheers,
> Jan

Thanks,
Ben

>
> [1] http://build.kde.org/
>
> --
> Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
>
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
>>> <<

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: configuring cppcheck on the CI

[Ben Cooksley]

On Wed, Jan 28, 2015 at 4:37 AM, Milian Wolff  wrote:
> Hello,

HI Milian,

>
> not sure where to ask this question. Cppcheck running on the CI is a great
> help - thanks for that! I'd like to configure it slightly though, as the three
> "errors" it reports for kdevplatform are actually false-positives:
>
> http://build.kde.org/job/kdevplatform_master_qt5/457/cppcheckResult/
>
> The first two errors are grantlee templates and should be ignored by cppcheck.
> The third is a missing define (where does cppcheck get those from?).

cppcheck is executed per the directives in the CI build script configuration.
Please see 
http://quickgit.kde.org/?p=websites%2Fbuild-kde-org.git&a=tree&hb=eda27c0bbcd26d4d124c15b082f09169b95c962b

You probably want to see the file config/build/global.cfg, which
defines the commands that all projects use unless extended by
cppcheckExtraArgs or overridden entirely by redefinition of
cppcheckCommand.

>
> Thanks
> --
> Milian Wolff
> m...@milianw.de
> http://milianw.de

Regards,
Ben

>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: configuring cppcheck on the CI

[Ben Cooksley]

On Thu, Jan 29, 2015 at 7:34 AM, Milian Wolff  wrote:
> On Wednesday 28 January 2015 19:30:40 Milian Wolff wrote:
>> On Wednesday 28 January 2015 18:18:51 Marko Käning wrote:
>> > Hi Milian,
>> >
>> > On 28 Jan 2015, at 16:59 , Milian Wolff  wrote:
>> > > OK, can you tell me how to tweak cppcheckExtraArgs for individual
>> > > projects,
>> > > e.g. kdevplatform for now?
>> >
>> > for this project currently exists this file:
>> > ---
>> > $ cd PATH_TO_BUILD-KDE-ORG
>> > $ cat config/build/kdevplatform/kf5-qt5.cfg
>> > [DEFAULT]
>> > configureExtraArgs=-DBUILD_COVERAGE=ON
>> >
>> > [QualityCheck]
>> > runCppcheck=True
>> >
>> > ---
>> > which ensures that cppcheck is run at all.
>> >
>> >
>> > Now you simply add your additional arguments ‘-foo' and ‘-bar' to
>> > cppcheckExtraArgs like this: ---
>> > $ cat config/build/kdevplatform/kf5-qt5.cfg
>> > [DEFAULT]
>> > configureExtraArgs=-DBUILD_COVERAGE=ON
>> >
>> > [QualityCheck]
>> > runCppcheck=True
>> > cppcheckExtraArgs=-foo -bar
>> >
>> > ---
>> > and commit it back to the production branch of b-k-o [1].
>>
>> Thanks!
>>
>> I only grepped for kdevplatform, and did not try to find anything that has
>> it in its name ;-) My bad!
>>
>> OK, so it's easy enough to add ignored paths, which I'll commit now. But I
>> wonder about the defines. Ben, why does the global config explicitly define
>>
>> -DKDE_IMPORT -DKDE_EXPORT
>>
>> in cppcheckCommand? By default, cppcheck would otherwise go over all defines
>> and ignore those that include #error - which would be exactly what I want
>> in kdevelop code. If instead -D is to be used, then we'd suddenly need to
>> add /all/ defines there. This triggers one error in KDevelop.
>>
>> Additionally, tons of files are ignored b/c the export macros are now
>> generated in the build folder, which is not added to the include paths.
>> Should we then add all include paths to cppcheck manually, and globally? Or
>> does someone know a better approach here? I only see the option to write a
>> custom script which gets the defines and include paths from the
>> CMake-generated compile_commands.json and then runs cppcheck on each target
>> with the configuration it gets from there. Still needs some hacks though to
>> work properly (i.e. I need to define __linux__ manually etc. pp., to
>> prevent errors in Qt headers that try to detect the system).
>>
>> For now, I'll just add more defines to the extra args, but I'd like to start
>> the discussion on how to handle this better in the future.
>
> How do I sent review requests for the configuration on build.kde.org?
>
> https://paste.kde.org/pl6lf9j4g

This can be done through Reviewboard, although I see you've found that now :)
I've committed your change now.

>
> --
> Milian Wolff
> m...@milianw.de
> http://milianw.de
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Thanks,
Ben

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Creating personal clone- Permission denied (publickey)

[Ben Cooksley]

On Fri, Feb 6, 2015 at 5:16 PM, anu mittal  wrote:
> ssh g...@git.kde.org clone  

Hi Anu,

>
> I have updated my ssh key at the KDE Identity and also have developer's
> access yet when i am trying to push my code ,it shows the error- Permission
> denied.
> and when I tried ssh-add -l the ssh key at server side does not match with
> the one I recently generated and updated at the KDE Identity account.
> How can I change ssh key at the server side, I am working on kubuntu 14.10
> plasma 4 desktop?

I would suggest checking the permissions on ~/.ssh/ as they are
probably too open for ssh to accept using any keys there.
As for the key fingerprint - the code to generate those is broken on
Identity. This doesn't affect the uploading of keys though - your new
key will be live.

>
> Anu.
>

Cheers,
Ben Cooksley
KDE Sysadmin

>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
>>> <<
>

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Creating personal clone- Permission denied (publickey)

[Ben Cooksley]

On Sat, Feb 7, 2015 at 9:31 PM, anu mittal  wrote:
> Thanks for the help, it worked there.
> But now when after creating the clone [1]  i am trying to push my code there
> I am getting the following error:
> http://pastebin.com/d4fAkdqD

You need to setup Git properly - please ensure the config items
"user.name" and "user.email" are set.
In particular, "user.name" should be set to your actual name - not
your Identity username.

You will also need to cleanse your commit of generated build files and
backups. This can be accomplished by running "git reset HEAD^" and
then re-adding the changes you wish to keep, and committing that.
Please do not use "git commit -a".

>
> [1] http://quickgit.kde.org/?p=clones%2Fkalzium%2Fanumittal%2Fporting.git
>

Cheers,
Ben

>
> On Fri, Feb 6, 2015 at 5:22 PM, Pablo Sanchez  wrote:
>>
>> [ Comments below, in-line ]
>>
>> On 02/06/2015 05:19 AM, Ben Cooksley wrote:
>>>
>>> I would suggest checking the permissions on ~/.ssh/ as they are
>>> probably too open for ssh to accept using any keys there.
>>
>>
>> Hi,
>>
>> To be clear, what Ben is saying is ensure the files in ~/.ssh are "chmod
>> 400"
>>
>> Cheers,
>>
>> --
>> Pablo Sanchez - Blueoak Database Engineering, Inc
>> Ph:819.459.1926 Blog:  http://pablo-blog.blueoakdb.com
>> iNum:  883.5100.0990.1054
>>
>>
>>
>>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
>>>> unsubscribe <<
>
>
>
>
> --
> Regards,
> Anu.
>
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
>>> <<
>

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: OCS providers.xml file should be served via https.

[Ben Cooksley]

On Fri, Mar 13, 2015 at 11:24 AM, Albert Astals Cid  wrote:
> El Dimecres, 11 de març de 2015, a les 12:31:55, ChALkeR va escriure:
>> I was told that it is ok to send this to a public ML.
>>
>> As it is now, OCS providers.xml file (
>> http://download.kde.org/ocs/providers.xml ) is served via http, which
>> breaks the https chain and allows a MitM attack replacing the actual
>> provider location url with malicious provider url. Or downgrading the
>> protocol to http and inserting payloads in actual content from kde-*.org on
>> the fly.
>>
>> Fixing it would require introducing an https server that serves the
>> providers.xml file (download.kde.org does not serve anything through
>> https), Ben Cooksley suggests copying that file to autoconfig.kde.org.
>>
>> After that, all *.knsrc files should get the ProvidersUrl changed to the
>> new location, and the old location could be removed after a couple of
>> years. Another way of fixing that would be to add yet another (temporary?)
>> hack to knewstuff that replaces one specific url with a new https one.
>>
>> On a side note, http://edu.kde.org/ should be replaced with
>> https://edu.kde.org/ in some places (including the knewstuff itself).
>>
>> Comments?
>
> Using https so people downloads can hot be hijacked sounds like a good thing
> :)

If there is no further feedback on this, I'd suggest a ticket be
opened requesting the file to be deployed on autoconfig.kde.org, then
review requests being filed against the relevant applications to
adjust their behaviour.

>
> Cheers,
>   Albert
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Regards,
Ben

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: CVS dump

[Ben Cooksley]

On Mon, Mar 16, 2015 at 8:56 AM, Thiago Macieira  wrote:
> On Sunday 15 March 2015 18:59:10 Pali Rohár wrote:
>> Hello,
>>
>> is there available for download full CVS dump of old cvs.kde.org
>> repository? Or if somebody still has it... can share it with me?
>
> All of the CVS repositories were imported into SVN and most of those have been
> migrated to Git. Anything you'd need from the CVS repository should also be
> found in Subversion and Git servers.

In any event if it is required, sysadmin does have a copy of the CVS
repository in our archives.
It is 2.8gb even heavily compressed however.

Regards,
Ben

>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>Software Architect - Intel Open Source Technology Center
>   PGP/GPG: 0x6EF45358; fingerprint:
>   E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: CVS dump

[Ben Cooksley]

On Mon, Mar 16, 2015 at 9:27 AM, Pali Rohár  wrote:
> On Sunday 15 March 2015 21:05:23 Ben Cooksley wrote:
>> On Mon, Mar 16, 2015 at 8:56 AM, Thiago Macieira
>>  wrote:
>> > On Sunday 15 March 2015 18:59:10 Pali Rohár wrote:
>> >> Hello,
>> >>
>> >> is there available for download full CVS dump of old
>> >> cvs.kde.org repository? Or if somebody still has it... can
>> >> share it with me?
>> >
>> > All of the CVS repositories were imported into SVN and most
>> > of those have been migrated to Git. Anything you'd need
>> > from the CVS repository should also be found in Subversion
>> > and Git servers.
>>
>> In any event if it is required, sysadmin does have a copy of
>> the CVS repository in our archives.
>> It is 2.8gb even heavily compressed however.
>>
>> Regards,
>> Ben
>>
>
> Nice. Is that CVS repository public (like git - as everybody can
> do 1:1 copy of it)? Or contains it some private/trusted data?

Unknown. I presume it is public though.

>
> How much work for sysadmins is to share that CVS dump? Years ago
> somebody told me that CVS repo is also available on dewey.kde.org
> but today after quick ssh look I have not seen any CVS archive...

I'll transfer a copy to Dewey now.

>
> --
> Pali Rohár
> pali.ro...@gmail.com

Cheers,
Ben

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Git does not pull all commits from the history

[Ben Cooksley]

On Sat, Mar 21, 2015 at 11:39 AM, Alexander Potashev
 wrote:
> Hi,

Hi Alexander,

>
> I noticed that not all of the commits from the KWordQuiz repository
> are present in my working clone.
>
> Let's start with my use case. I tried to track down where a i18n
> string was broken and "git blame" pointed me to a merge commit
> (e2d5c497 "
> Merge frameworks branch into master" [1]). The first problem was that,
> because there was a merge, I couldn't easily see what exact commits
> from the merged sequence of commits was guiltly.
>
> OK, I decided to see them all. No such luck - those commits do not
> exist in my clone, i.e. "git show
> 7c708a619e344c6b835eaa7753518ee8ace24861" does not work for example.
> But if I watch it in at projects.kde.org, it works! [2]
>
> Two questions:
>  1. How can I pull those obscure commits from the server? I guess a
> normal "git clone" did not pull them because the "frameworks" branch
> the merge has been done from is now gone.

It isn't gone, not entirely anyway.
All repositories on git.kde.org are protected by a backup mechanism
within our hooks which preserves refs in the event of destructive
operations.

These can be found under refs/backups/* and cannot be altered (the
hooks won't permit you to do anything to these refs).

>  2. If someone runs "git gc" on the server, will the respective Git
> objects for those commits be removed permanently?

Due to the above backup refs, no commits will ever be lost due to git
gc or repacking.

>
> [1] 
> https://projects.kde.org/projects/kde/kdeedu/kwordquiz/repository/revisions/e2d5c497e8e9e41b3b5adf94bb4ec23422292c00
> [2] 
> https://projects.kde.org/projects/kde/kdeedu/kwordquiz/repository/revisions/7c708a619e344c6b835eaa7753518ee8ace24861
>
> --
> Alexander Potashev

Regards,
Ben

>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Git does not pull all commits from the history

[Ben Cooksley]

On Sat, Mar 21, 2015 at 6:01 PM, Alexander Potashev
 wrote:
> 2015-03-21 1:50 GMT+03:00 Luigi Toscano :
>> That's not a merge commit: it even says "Squashed commit of the following:",
>> so all the commits have been merged together and applied on top of master, if
>> I see the history correctly. The frameworks branch is still there, 
>> independent
>> from master.
>> You can track it locally as usual with:
>> git checkout -t remotes/origin/frameworks
>
> Luigi, Ben,
>
> Thanks for the clarification on merging as a squashed commit.
>
> I'm pretty sure there's no frameworks branch anymore because:
>  1. The "git checkout" command you suggested doesn't work for me, Git says
> "Did you intend to checkout 'remotes/origin/frameworks' which can not
> be resolved as commit?", even after I did all the "git remote update"
> / "git fetch".
>  2. It's missing from the output of "git branch -a".
>  3. The KWordQuiz project page [1] shows no "frameworks" branch in the
> combo box.
>
> Ben, can you please clarify how to fetch those backups? I don't see
> any relevant branches by running "git branch -a".

Backups can be retrieved by running something along these lines I believe:

git fetch  +refs/backups/*:refs/backups/*

To get a listing of backup refs you've retrieved, you can run:

git ls-remote . | grep refs/backups/

The names of backup refs take the form of --

So a branch named frameworks could be found at
refs/backups/branch-frameworks- where  is when
it was deleted.

>
> [1] https://projects.kde.org/projects/kde/kdeedu/kwordquiz/repository
>
> --
> Alexander Potashev

Regards,
Ben

>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Knotify just doesnt work

[Ben Cooksley]

On Sun, Mar 22, 2015 at 9:20 PM, Alexandro Colorado  wrote:
> I want to bring attention to a frustrating experience about using knotify. I

Hi Alexandro,

> get notifications from many KDE apps, Kopete, Kmail, knetwork manager, etc.
> However is frustrating that the notification never actually do anything
> else. Meaning that the notification has a button (at least on kopete) to
> view or close.
> I think this is a big bug, since the notifications are supposed to be links
> to the application. Otherwise what is the point of notifying. Like I joked
> wiht a developer "is like an annoying sister, letting you know your mom
> called you but when you ask her what she said, she just run away saying, go
> and find it out".
> Not only that but other notification engines do exactly that, take firefox
> notifications, it takes you the screen AND TAB of the browser. Doesnt matter
> if its in the current desktop or across the other virtual desktops.
>
> Please take care of this since I think is a big workflow hiccup.
>
> Regards.
>
> PD: I tried to add it to the issues.kde.org but unfortunately the identity
> engine of KDE is also pretty obscure.

issues.kde.org does not exist, perhaps you were referring to bugs.kde.org?
In regards to problems accessing KDE infrastructure, please contact
sysad...@kde.org.

>
> --
> Alexandro Colorado
> Apache OpenOffice Contributor
> 882C 4389 3C27 E8DF 41B9  5C4C 1DB7 9D1C 7F4C 2614
>

Regards,
Ben Cooksley
KDE Sysadmin

>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
>>> <<
>

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Phabricator Maniphest - workflow for 'normal' user?

[Ben Cooksley]

On Thu, Jun 25, 2015 at 12:46 AM, Luigi Toscano
 wrote:
> On Wednesday 24 of June 2015 14:32:23 Jaroslaw Staniek wrote:
>> Hi,
>> Bugzilla with all its issues was a bit customized for our needs and
>> had a workflow familiar for average user of KDE software and services.
>> As we're heading to a switch to the Phabricator Maniphest [1] (so far
>> the support from our Sysadmin Team is great!), I'd like to hear
>> opinions and ideas how it can be made wrapped into something trivial
>> to use.
>
> I don't have ideas for Phabricator as I couldn't play with it so far. But just
> to be clear "we" as Calligra or "we" as KDE? In both cases, I thought that we
> were going to evaluate first, and in any case the bug handling part was not in
> the center of the discussion for now (more focus on code review, tasks, but
> not bugs for now - not before result reports and migration plans I haven't
> seen at all around).

I can confirm we're still in the evaluation phase.

At this time the task tracking features of Phabricator are intended to
be used as a replacement for todo.kde.org (Kanboard) rather than as a
replacement for bugs.kde.org if it is selected.

>
> Ciao
> --
> Luigi

Regards,
Ben

>
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Question about KDE4 Application long time support

[Ben Cooksley]

On Sun, Jul 5, 2015 at 11:10 PM, Ralf Habacker  wrote:
>
>
> Am 05.07.2015 um 12:17 schrieb Albert Astals Cid:
>> El Diumenge, 5 de juliol de 2015, a les 12:03:35, Ralf Habacker va escriure:
>>> Am 18.05.2015 um 13:26 schrieb Albert Astals Cid:
 My suggestion for you if you really want to maintain a longer term
 kdelibs4- based version of umbrello s to keep doing commits in your
 "last" kdelibs4- branch (i guess Applications/15.04 in this case), though
 since we're not doing any more tarballs of those i'm not sure it will
 reach many people, you'll have to ping distro people and tell them to
 look into the branch regularly for bugfixes or you can try releasing your
 own tarballs.
>>> According to the available number of distributions
>>> https://en.wikipedia.org/wiki/List_of_Linux_distributions#Official_distribut
>>> ions you are aware that this will require noticable efforts to perform for
>>> every release ?
>> I am, but given that you want to release two versions of the same app and we
>> don't support that is the best I could suggest.
> You are also aware, that Windows and Mac OSX installation support is
> currently broken (KF5 applications could not find distributed data
> files, see https://bugreports.qt.io/browse/QTBUG-44473) and requires to
> stay for that platforms with KDE4, while KF5 is usable for unix like os ?
>
> Forcing to choose one framework results into give up either linux (stay
> with KDE4) or Windows and Mac/OSx (switch to KF5)

I can't comment on OSX, but for Windows you can fix this by renaming
$prefix/share/ to $prefix/data/ and moving the contents of
$prefix/bin/ to $prefix/
At least that is the theory, no idea if it will actually work.

>
> Cheers
> Ralf

Regards,
Ben

>
>> Cheers,
>>   Albert
>>
>>> Cheers
>>> Ralf
>>>
> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
> <<
>
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Help wanted to evolve KDEs music players

[Ben Cooksley]

On Tue, Aug 4, 2015 at 10:18 PM, Martin Sandsmark
 wrote:
> On Tue, Aug 04, 2015 at 10:41:45AM +0200, Harald Sitter wrote:
>> During last akademy I brought up the possibility of killing
>> phonon-gstreamer and going vlc-only in Phonon. While this discussion
>> happened on a private packager list I can not point to it but the gist
>> of it was that Fedora doesn't have VLC, OpenSUSE has a "crippled" VLC
>> and Slackware doesn't have any packages and probably will not ever.
>
> Why don't they provide VLC?
>
>
>> KDE Sysadmins raised concerns that we wouldn't be able to provide VLC
>> in any sort of bundled binary fashion as our mirror network covers
>> many jurisdictions where VLC might be problematic (not that I think we
>> would want to distribute binaries containing VLC anyway although it is
>> very much a possibility with windows/osx I have been told).
>
> Videolan itself has a ton of mirrors all over the world, which parts of the
> world does KDE have mirrors that Videolan doesn't? (And also same question
> as above.)

We can't speak for our mirrors in terms of legal risk - those hosting
VLC in the questionable countries may have decided they'll take the
risk.
The USA is the obvious problem country there...

>
> And in my humble opinion, that some distros cripple themselves shouldn't be
> our problem... If a distro doesn't provide what users need, users should use
> another distro.
>
> --
> Martin Sandsmark

Cheers,
Ben

>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Help wanted to evolve KDEs music players

[Ben Cooksley]

On Tue, Aug 4, 2015 at 10:38 PM, Martin Sandsmark
 wrote:
> On Tue, Aug 04, 2015 at 10:28:35PM +1200, Ben Cooksley wrote:
>> We can't speak for our mirrors in terms of legal risk - those hosting
>> VLC in the questionable countries may have decided they'll take the
>> risk.
>> The USA is the obvious problem country there...
>
> But what kind of legal risk are we talking about here?

The same one Redhat / Fedora don't like at all, and which SUSE is
working around...

>
> I can't really see why VLC would be worse than pretty much anything else we
> ship in terms of patents, for example (there are patents covering a ton of
> stuff we do).
>
> If it is the DVD de-scrambling that is in a separate library, and AFAIK it is
> fairly straight-forward to just build libdvdread and/or VLC without that
> dependency. From some simple googling it seems like fedora already ships a
> libdvdread without de-scrambling enabled, for example.
>
> --
> Martin Sandsmark

Regards,
Ben

>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

kde-workspace repository locked

[Ben Cooksley]

Hi all,

Per the request of the Plasma team, the kde-workspace repository on
git.kde.org has now been locked to prevent any further changes.

If there are any problems with this, please let us know.

Cheers,
Ben Cooksley
KDE Sysadmin

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[kde-workspace] /: Add readme explaining repo closure.

[Ben Cooksley]

Git commit 257b997132217fd73a1b3be14db49735b64235e7 by Ben Cooksley.
Committed on 28/09/2015 at 08:40.
Pushed by bcooksley into branch 'master'.

Add readme explaining repo closure.
CCMAIL: kde-core-de...@kde.org
CCMAIL: kde-devel@kde.org

A  +2-0README.md

http://commits.kde.org/kde-workspace/257b997132217fd73a1b3be14db49735b64235e7

diff --git a/README.md b/README.md
new file mode 100644
index 000..0743dd9
--- /dev/null
+++ b/README.md
@@ -0,0 +1,2 @@
+Note: this repository is now closed for further commits, as it is no longer 
being released.
+New contributions should instead be made to the Plasma 5 repositories.

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Phabricator Questions

[Ben Cooksley]

On Wed, Oct 28, 2015 at 10:47 PM, Milian Wolff  wrote:
> Hey all,

Hi Milian,

>
> I got a few questions regarding Phabricator, can anyone answer them for me:
>
> * Can I merge a change request using the web UI? If not, how exactly do I use
> arc to merge a request I know via it's phabricator URL?
>
> * On the main website (https://phabricator.kde.org/) the dashboard shows me an
> "Unbreak Now!" list with tasks from WikiToLearn and GCompris, both of which
> I'm not interested in. How do I configure this list? In general, is there a
> way for me to configure phabricator such that it only lists stuff that I'm
> actually interested in? With KDE on Phabricator becoming larger and larger, I
> fear I'll drown in unrelated stuff.
>
> * In general, is there a way to configure the main website more to my likings,
> to show queries I'm actually interested in? That would solve the above.

Phabricator is extremely customisable, on a per-user basis in this
regard. Please use the Dashboards application to create a personal
dashboard, which you can then set as the front page. These dashboards
can then be shared with other users if you wish.

>
> Thanks

Regards,
Ben

> --
> Milian Wolff
> m...@milianw.de
> http://milianw.de

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Phabricator Questions

[Ben Cooksley]

On Thu, Oct 29, 2015 at 6:55 AM, Milian Wolff  wrote:
> On Thursday, October 29, 2015 6:14:22 AM CET Ben Cooksley wrote:
>> On Wed, Oct 28, 2015 at 10:47 PM, Milian Wolff  wrote:
>> > Hey all,
>>
>> Hi Milian,
>>
>> > I got a few questions regarding Phabricator, can anyone answer them for
>> > me:
>> >
>> > * Can I merge a change request using the web UI? If not, how exactly do I
>> > use arc to merge a request I know via it's phabricator URL?
>> >
>> > * On the main website (https://phabricator.kde.org/) the dashboard shows
>> > me an "Unbreak Now!" list with tasks from WikiToLearn and GCompris, both
>> > of which I'm not interested in. How do I configure this list? In general,
>> > is there a way for me to configure phabricator such that it only lists
>> > stuff that I'm actually interested in? With KDE on Phabricator becoming
>> > larger and larger, I fear I'll drown in unrelated stuff.
>> >
>> > * In general, is there a way to configure the main website more to my
>> > likings, to show queries I'm actually interested in? That would solve the
>> > above.
>>
>> Phabricator is extremely customisable, on a per-user basis in this
>> regard. Please use the Dashboards application to create a personal
>> dashboard, which you can then set as the front page. These dashboards
>> can then be shared with other users if you wish.
>
> That is nice!
>
> For others: You first need to create custom queries, then you can select them
> in the dashboard. Not very intuitive, but it seems to work:
>
> https://phabricator.kde.org/dashboard/manage/8/
>
> This brings me to another question: What is a project on Phabricator? Just a
> collection of tasks and people?

Essentially it is, yes.

> I don't seem to be able to associate repositories with a project or vice
> versa, so one needs to manually lists repositories in a commit feed, right?

Repositories are associated with projects from the repository editor
interface. Unfortunately as this same screen offers the controls for
disabling force pushes and controlling who can push to the repository,
this can only be changed by Sysadmins.

Regards,
Ben

>
> Cheers
> --
> Milian Wolff
> m...@milianw.de
> http://milianw.de

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Phabricator Questions

[Ben Cooksley]

On Fri, Oct 30, 2015 at 12:52 AM, Martin Graesslin  wrote:
> On Thursday, October 29, 2015 12:31:23 PM CET Milian Wolff wrote:
>> > In general, can we configure Phabricator somehow to be more open _by
>> > default_? I don't want to force people to login just to look at what's
>> > going on in KDE land.
>>
>> ^-- this becomes more relevant now. If, by default, everything is public
>> then issues such as the one above don't occur. Can we configure that
>> somehow?
>
> +1 for open by default (if that's possible)

Unfortunately Phabricator does not permit you to change the defaults
of Panels at this time, at least with the version we are running.
Unless i've missed something that is.

>
> Cheers
> Martin

Regards,
Ben

>
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
>

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Phabricator Questions

[Ben Cooksley]

On Mon, Nov 2, 2015 at 10:35 AM, Matthias Klumpp  wrote:
> 2015-11-01 22:31 GMT+01:00 Albert Astals Cid :
>> El Sunday 01 November 2015, a les 21:17:03, Ben Cooksley va escriure:
>>> On Fri, Oct 30, 2015 at 12:52 AM, Martin Graesslin 
>> wrote:
>>> > On Thursday, October 29, 2015 12:31:23 PM CET Milian Wolff wrote:
>>> >> > In general, can we configure Phabricator somehow to be more open _by
>>> >> > default_? I don't want to force people to login just to look at what's
>>> >> > going on in KDE land.
>>> >>
>>> >> ^-- this becomes more relevant now. If, by default, everything is public
>>> >> then issues such as the one above don't occur. Can we configure that
>>> >> somehow?
>>> >
>>> > +1 for open by default (if that's possible)
>>>
>>> Unfortunately Phabricator does not permit you to change the defaults
>>> of Panels at this time, at least with the version we are running.
>>> Unless i've missed something that is.
>>
>> Forcing people to log in just to have a peek is indeed not nice, have we 
>> asked
>> upstream about it?
>
> Actually, Phabricator has very fine-grained permission control. We use
> that at Tanglu (http://tracker.tanglu.org).
> Just switch the policy.allow-public setting to true, and the use the

That is already enabled.

> Applications panel to limit write access to Phabricator modules to
> specific users or groups or project members (or any combination of
> those).

Unfortunately the Dashboard application settings do not allow changing
the default permissions for Panels / Dashboards.

> Cheers,
> Matthias

Thanks,
Ben

>
> --
> Debian Developer | Freedesktop-Developer
> I welcome VSRE emails. See http://vsre.info/
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Phabricator Questions

[Ben Cooksley]

On Mon, Nov 2, 2015 at 10:31 AM, Albert Astals Cid  wrote:
> El Sunday 01 November 2015, a les 21:17:03, Ben Cooksley va escriure:
>> On Fri, Oct 30, 2015 at 12:52 AM, Martin Graesslin 
> wrote:
>> > On Thursday, October 29, 2015 12:31:23 PM CET Milian Wolff wrote:
>> >> > In general, can we configure Phabricator somehow to be more open _by
>> >> > default_? I don't want to force people to login just to look at what's
>> >> > going on in KDE land.
>> >>
>> >> ^-- this becomes more relevant now. If, by default, everything is public
>> >> then issues such as the one above don't occur. Can we configure that
>> >> somehow?
>> >
>> > +1 for open by default (if that's possible)
>>
>> Unfortunately Phabricator does not permit you to change the defaults
>> of Panels at this time, at least with the version we are running.
>> Unless i've missed something that is.
>
> Forcing people to log in just to have a peek is indeed not nice, have we asked
> upstream about it?

This only affects *default* settings - as long as people change the
settings of Panels and Dashboards they create to Public, then
everything will work correctly.

>
> Cheers,
>   Albert

Regards,
Ben

>
>>
>> > Cheers
>> > Martin
>>
>> Regards,
>> Ben
>>
>> >>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
>> >>> unsubscribe <<>>
>> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
>> >> <<
>

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<