T13975: Move hanyoung/libkweather to frameworks/kweathercore

2020-12-20 Thread Ben Cooksley
bcooksley closed this task as "Resolved".
bcooksley claimed this task.
bcooksley added a comment.


  As the repository has yet to transit through KDE Review and then receive the 
subsequent approval to join Frameworks, it is ineligible to move to 
https://invent.kde.org/frameworks/ i'm afraid.
  
  I've therefore moved the repository to the libraries/ namespace instead, and 
have released the repository into KDE Review - a process which you can now 
start by emailing kde-core-devel in accordance with the KDE Software Lifecycle.

TASK DETAIL
  https://phabricator.kde.org/T13975

To: bcooksley
Cc: bcooksley, sysadmin, kde-frameworks-devel, hanyoung, duffus


Re: RFC: Switching to min Qt version 5.14 for KF on December 14th

2020-12-06 Thread Ben Cooksley
On Mon, Dec 7, 2020 at 6:05 AM David Faure  wrote:

> On dimanche 6 décembre 2020 17:39:38 CET Albert Astals Cid wrote:
> >  * MidnightBSD
> >  * openBSD
> > The BSDs are a bit more unfortunate.
>
> Thanks for the information, Albert.
>
> Apparently this means bumping the requirement to Qt 5.14 would break
> OpenBSD.
>
> How can we reach OpenBSD KDE people?
> CC'ing kde-free...@kde.org, I know it's not the same, but maybe you guys
> know?
> ;)
>

The "distribution point of contacts" list that Sysadmin maintains says
openbsd-...@googlegroups.com is the appropriate mailing list for KDE on
OpenBSD.

Cheers,
Ben


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


Re: Merge tags in master branch?

2020-11-28 Thread Ben Cooksley
On Sun, Nov 29, 2020 at 10:16 AM David Faure  wrote:

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

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

Cheers,
Ben


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


[sysadmin/ci-tooling] /: Fully purge support for Qt 5.12 and Qt 5.13 builds from the CI infrastructure.

2020-11-26 Thread Ben Cooksley
Git commit d09a4d5a149eb1c7f47bd7323fadcb2f21c7e3e0 by Ben Cooksley.
Committed on 27/11/2020 at 07:54.
Pushed by bcooksley into branch 'master'.

Fully purge support for Qt 5.12 and Qt 5.13 builds from the CI infrastructure.

CCMAIL: kde-frameworks-devel@kde.org

M  +0-2archive-configs/production.yaml
M  +0-2archive-configs/sandbox.yaml
D  +0-9build-specs/Applications/akonadi-SUSEQt5.12.yaml
R  +1-1custom-jobs/Extragear craft master SUSEQt5.14.pipeline [from: 
custom-jobs/Extragear craft master SUSEQt5.12.pipeline - 098% similarity]
M  +1-1custom-jobs/known-jobs.json
M  +0-2helpers/check-platform.py
M  +2-2helpers/extract-cmake-dependency-metadata.py
M  +2-2helpers/generate-dependency-diagram-data.py
M  +1-1local-metadata/abi-compliance-checker.yaml
M  +0-6local-metadata/project-ignore-rules.yaml
D  +0-212  pipeline-templates/Frameworks/SUSEQt5.12.template
D  +0-1pipeline-templates/Frameworks/SUSEQt5.13.template
M  +1-1pipeline-templates/Frameworks/SUSEQt5.14.template
T  +212  -1pipeline-templates/Frameworks/SUSEQt5.15.template
D  +0-192  pipeline-templates/SUSEQt5.12.template
D  +0-1pipeline-templates/SUSEQt5.13.template
M  +1-1pipeline-templates/SUSEQt5.14.template
T  +192  -1pipeline-templates/SUSEQt5.15.template
M  +1-1pipeline-templates/dependency-build/AndroidQt5.15.template
D  +0-65   pipeline-templates/dependency-build/SUSEQt5.12.template
D  +0-1pipeline-templates/dependency-build/SUSEQt5.13.template
M  +1-1pipeline-templates/dependency-build/SUSEQt5.14.template
T  +65   -1pipeline-templates/dependency-build/SUSEQt5.15.template
D  +0-217  system-images/suse-qt512/Dockerfile
D  +0-221  system-images/suse-qt513/Dockerfile

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

diff --git a/archive-configs/production.yaml b/archive-configs/production.yaml
index 11de746..33d5176 100644
--- a/archive-configs/production.yaml
+++ b/archive-configs/production.yaml
@@ -10,8 +10,6 @@ server:
 
 cacheLocation:
   WindowsMSVCQt5.15: "C:\\CI\\archives\\WindowsMSVCQt5.15\\"
-  SUSEQt5.12: "/srv/archives/production/SUSEQt5.12/"
-  SUSEQt5.13: "/srv/archives/production/SUSEQt5.13/"
   SUSEQt5.14: "/srv/archives/production/SUSEQt5.14/"
   SUSEQt5.15: "/srv/archives/production/SUSEQt5.15/"
   FreeBSDQt5.15: "/usr/home/jenkins/archives/production/"
diff --git a/archive-configs/sandbox.yaml b/archive-configs/sandbox.yaml
index 80bb5c8..d719e8c 100644
--- a/archive-configs/sandbox.yaml
+++ b/archive-configs/sandbox.yaml
@@ -10,8 +10,6 @@ server:
 
 cacheLocation:
   WindowsMSVCQt5.15: "C:\\CI\\sandbox-archives\\WindowsMSVCQt5.15\\"
-  SUSEQt5.12: "/srv/archives/sandbox/SUSEQt5.12/"
-  SUSEQt5.13: "/srv/archives/sandbox/SUSEQt5.13/"
   SUSEQt5.14: "/srv/archives/sandbox/SUSEQt5.14/"
   SUSEQt5.15: "/srv/archives/sandbox/SUSEQt5.15/"
   FreeBSDQt5.15: "/usr/home/jenkins/archives/sandbox/"
diff --git a/build-specs/Applications/akonadi-SUSEQt5.12.yaml 
b/build-specs/Applications/akonadi-SUSEQt5.12.yaml
deleted file mode 100644
index d8b7697..000
--- a/build-specs/Applications/akonadi-SUSEQt5.12.yaml
+++ /dev/null
@@ -1,9 +0,0 @@
-kf5-qt5:
-  "ctest-arguments": "--verbose"
-  run-tests: True
-  per-test-timeout: 60
-
-stable-kf5-qt5:
-  "ctest-arguments": "--verbose"
-  run-tests: True
-  per-test-timeout: 60
diff --git a/custom-jobs/Extragear craft master SUSEQt5.12.pipeline 
b/custom-jobs/Extragear craft master SUSEQt5.14.pipeline
similarity index 98%
rename from custom-jobs/Extragear craft master SUSEQt5.12.pipeline
rename to custom-jobs/Extragear craft master SUSEQt5.14.pipeline
index 63dc9ba..e7e94cf 100644
--- a/custom-jobs/Extragear craft master SUSEQt5.12.pipeline
+++ b/custom-jobs/Extragear craft master SUSEQt5.14.pipeline
@@ -1,5 +1,5 @@
 // Request a node to be allocated to us
-node( "SUSEQt5.12" ) {
+node( "SUSEQt5.14" ) {
 // We want Timestamps on everything
 timestamps {
// We want to catch any errors that occur to allow us to send out 
notifications (ie. emails) if needed
diff --git a/custom-jobs/known-jobs.json b/custom-jobs/known-jobs.json
index 22d41e6..d4bb552 100644
--- a/custom-jobs/known-jobs.json
+++ b/custom-jobs/known-jobs.json
@@ -1,3 +1,3 @@
 [
-   {"name": "Extragear craft master SUSEQt5.12"}
+   {"name": "Extragear craft master SUSEQt5.14"}
 ]
diff --git a/helpers/check-platform.py b/helpers/check-platform.py
index 6e2fb26..d6832ab 100644
--- a/helpers/check-platform.py
+++ b/helpers/check-platform.py
@@ -11,8 +11,6 @@ parser.add_argument('metainfo', nargs='+', 
help='metainfo.yaml files', type=str)
 arguments = parser.parse_args()
 
 allPlatfor

[sysadmin/ci-tooling] local-metadata: Phase out SUSEQt5.12 builds for Frameworks now that it is no longer supported.

2020-11-26 Thread Ben Cooksley
Git commit 6a9cee7ffefe9cfdfd3d9e99271f53e808ca5ca3 by Ben Cooksley.
Committed on 27/11/2020 at 07:29.
Pushed by bcooksley into branch 'master'.

Phase out SUSEQt5.12 builds for Frameworks now that it is no longer supported.

CCMAIL: kde-frameworks-devel@kde.org

M  +1-1local-metadata/product-definitions.yaml

https://invent.kde.org/sysadmin/ci-tooling/commit/6a9cee7ffefe9cfdfd3d9e99271f53e808ca5ca3

diff --git a/local-metadata/product-definitions.yaml 
b/local-metadata/product-definitions.yaml
index e9e3df4..b817d7e 100644
--- a/local-metadata/product-definitions.yaml
+++ b/local-metadata/product-definitions.yaml
@@ -3,7 +3,7 @@
 - repositories:
   - "frameworks/*"
   platforms:
-  - "SUSEQt5.12"
+  - "SUSEQt5.14"
   - "SUSEQt5.15"
   - "WindowsMSVCQt5.15"
   - "FreeBSDQt5.15"


Restriction on bulk and automated changes to Git repositories

2020-10-23 Thread Ben Cooksley
Hi all,

As some of you will be aware, over the past week KDE.org infrastructure has
experienced some issues with services being overloaded by automated bots.
Coupled with a series of bulk changes that developers have pushed over the
past week, this has left us with some cleanup work that needs to be
performed.

To allow for necessary cleanup work from this to be conducted cleanly,
quickly and efficiently, we need to temporarily restrict the types of
changes that developers make.

As such, for the next 3 days (covering the period 24 - 26 October 2020),
performing bulk changes of any form to KDE Git repositories is prohibited.
Bulk change is defined as affecting more than 1 repository with the same or
similar change in a short period of time.

This includes changes such as version and dependency bumps, code style
cleanups, renames, adding of configuration files, and any other change that
is repeatable across multiple repositories in an automated manner.

No exception is given to release preparation activities, and any release
that would require the above to be performed should be considered to have
been postponed.

Regards,
Ben Cooksley
KDE Sysadmin


Re: Windows CI Updated to Qt 5.15 - Temporarily KO due to Breeze Icons Breakage

2020-10-19 Thread Ben Cooksley
On Mon, Oct 19, 2020 at 10:35 AM David Faure  wrote:

> On mardi 6 octobre 2020 11:59:34 CEST Ben Cooksley wrote:
> > Hi all,
> >
> > This evening i've completed updates to the Windows CI system, bringing it
> > from the previous Qt 5.14 setup it was using up to the more recent Qt
> 5.15.
> > As part of this various other libraries will have also been updated.
> >
> > This update was prompted by an unannounced dependency change within
> Breeze
> > Icons. As a reminder to all developers, it is imperative that any change
> to
> > your dependencies on a non-KDE project be announced two weeks or more in
> > advance.
> >
> > Unfortunately due to regressions within Breeze Icons, it is not possible
> > for the Dependency Builds to complete at this time, meaning Windows CI
> > functionality will be generally unavailable until this is corrected.
> >
> > The failure log can be found at
> >
> https://build.kde.org/job/Administration/job/Dependency%20Build%20Extragear%
> > 20stable-kf5-qt5%20WindowsMSVCQt5.15/lastFailedBuild/console
>
> That looks like the usual java timeout
>

At the time the link was sent, it referred to
https://build.kde.org/job/Administration/job/Dependency%20Build%20Extragear%20stable-kf5-qt5%20WindowsMSVCQt5.15/2/console
which was a compilation failure.


>
> I re-ran the exact same job and it passed.
>

Things are correct now yes.


>
> Can you re-enable normal CI service for Windows?
> I noticed e.g. that KIO tests were not run anymore...
>

Normal CI service has already been restored.

Execution of KIO's tests has been disabled as they very reliably leave
behind a kioslave5.exe process which cannot be terminated except by human
intervention (at least not using the tools i've tried using). This latent
process causes not only the KIO build to fail at the end, but also causes
all other builds assigned to that builder to fail until manual intervention
takes place.

It is not known what KIO is doing that causes this issue - however I have a
suspicion it is something to do with threads.


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


CI Breakage in Solid on FreeBSD

2020-10-15 Thread Ben Cooksley
Hi all,

Yesterday changes were landed to Solid, allowing it to make use of new
libimobiledevice API. Unfortunately these changes failed to handle the
situation where an older version of libimobiledevice is in use, causing a
build failure on FreeBSD.

This change to Solid is therefore considered to be an unnotified dependency
bump and will need to either be urgently corrected, or the change will need
to be reverted.

This is preventing the Dependency Build jobs from being executed on
FreeBSD, which has in turn made all CI builds for the platform
unmaintainable.

More pressingly, it is now an issue because recent changes landed in
kcmutils require that the Dependency Build jobs be triggered to eliminate
CMake related source incompatible changes.

This breakage prevents this from taking place and means the Plasma FreeBSD
jobs are broken until further notice.

Regards,
Ben Cooksley
KDE Sysadmin


Re: Windows CI Updated to Qt 5.15 - Temporarily KO due to Breeze Icons Breakage

2020-10-06 Thread Ben Cooksley
On Wed, Oct 7, 2020 at 4:49 AM Nate Graham  wrote:

> We are trying to fix the test failure. See
>
> https://invent.kde.org/frameworks/breeze-icons/-/commit/8fce580335ef86f19df2238f00270820ac74c9f4#note_115164
> for the current status.
>

This is a complete build failure, rather than just a test failure - as
noted in the log above.

I'm not sure what the script in question is trying to achieve though?


>
> Or was the regression caused by something else?
>
> Nate
>

Cheers,
Ben


>
>
>
> On 10/6/20 3:59 AM, Ben Cooksley wrote:
> > Hi all,
> >
> > This evening i've completed updates to the Windows CI system, bringing
> > it from the previous Qt 5.14 setup it was using up to the more recent Qt
> > 5.15. As part of this various other libraries will have also been
> updated.
> >
> > This update was prompted by an unannounced dependency change within
> > Breeze Icons. As a reminder to all developers, it is imperative that any
> > change to your dependencies on a non-KDE project be announced two weeks
> > or more in advance.
> >
> > Unfortunately due to regressions within Breeze Icons, it is not possible
> > for the Dependency Builds to complete at this time, meaning Windows CI
> > functionality will be generally unavailable until this is corrected.
> >
> > The failure log can be found at
> >
> https://build.kde.org/job/Administration/job/Dependency%20Build%20Extragear%20stable-kf5-qt5%20WindowsMSVCQt5.15/lastFailedBuild/console
> >
> > Once the Breeze Icons failure has been corrected, we expect to be able
> > to resume normal CI service for Windows.
> >
> > Regards,
> > Ben Cooksley
> > KDE Sysadmin
>
>


Windows CI Updated to Qt 5.15 - Temporarily KO due to Breeze Icons Breakage

2020-10-06 Thread Ben Cooksley
Hi all,

This evening i've completed updates to the Windows CI system, bringing it
from the previous Qt 5.14 setup it was using up to the more recent Qt 5.15.
As part of this various other libraries will have also been updated.

This update was prompted by an unannounced dependency change within Breeze
Icons. As a reminder to all developers, it is imperative that any change to
your dependencies on a non-KDE project be announced two weeks or more in
advance.

Unfortunately due to regressions within Breeze Icons, it is not possible
for the Dependency Builds to complete at this time, meaning Windows CI
functionality will be generally unavailable until this is corrected.

The failure log can be found at
https://build.kde.org/job/Administration/job/Dependency%20Build%20Extragear%20stable-kf5-qt5%20WindowsMSVCQt5.15/lastFailedBuild/console

Once the Breeze Icons failure has been corrected, we expect to be able to
resume normal CI service for Windows.

Regards,
Ben Cooksley
KDE Sysadmin


[sysadmin/ci-tooling] build-specs/Frameworks: Try re-enabling tests on Windows for KIO.

2020-09-19 Thread Ben Cooksley
Git commit a203a2dfa7ac5499e375fe7180f04071c278c9c9 by Ben Cooksley.
Committed on 19/09/2020 at 09:49.
Pushed by bcooksley into branch 'master'.

Try re-enabling tests on Windows for KIO.

CCMAIL: kde-frameworks-devel@kde.org

D  +0-5build-specs/Frameworks/kio-WindowsMSVCQt5.14.yaml

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

diff --git a/build-specs/Frameworks/kio-WindowsMSVCQt5.14.yaml 
b/build-specs/Frameworks/kio-WindowsMSVCQt5.14.yaml
deleted file mode 100644
index b235a3b..000
--- a/build-specs/Frameworks/kio-WindowsMSVCQt5.14.yaml
+++ /dev/null
@@ -1,5 +0,0 @@
-kf5-qt5:
-  run-tests: False
-
-stable-kf5-qt5:
-  run-tests: False


[sysadmin/ci-tooling] helpers: Ensure all variants of names that kioslave.exe can hide under are found and killed after running tests to ensure our builders don't get stuck,

2020-09-19 Thread Ben Cooksley
Git commit 5c55d45159099d6addff47776b62b8699ce750e9 by Ben Cooksley.
Committed on 19/09/2020 at 09:47.
Pushed by bcooksley into branch 'master'.

Ensure all variants of names that kioslave.exe can hide under are found and 
killed after running tests to ensure our builders don't get stuck,

CCMAIL: kde-frameworks-devel@kde.org

M  +2-1helpers/run-tests.py

https://invent.kde.org/sysadmin/ci-tooling/commit/5c55d45159099d6addff47776b62b8699ce750e9

diff --git a/helpers/run-tests.py b/helpers/run-tests.py
index 42e3a08..14fbe06 100755
--- a/helpers/run-tests.py
+++ b/helpers/run-tests.py
@@ -211,8 +211,9 @@ if sys.platform == 'win32':
subprocess.call("taskkill /f /T /im kdeinit5.exe", shell=True)
subprocess.call("taskkill /f /T /im test_crasher.exe", shell=True)
subprocess.call("taskkill /f /T /im dbus-daemon.exe", shell=True)
-   time.sleep( 60 )
+   time.sleep( 30 )
subprocess.call("taskkill /f /T /im kioslave.exe", shell=True)
+   subprocess.call("taskkill /f /T /im kioslave5.exe", shell=True)
subprocess.call("taskkill /f /T /im vctip.exe", shell=True)
 
 if sys.platform == 'freebsd12':


Re: KIO on Android Failure

2020-08-20 Thread Ben Cooksley
On Thu, Aug 20, 2020 at 8:00 AM David Faure  wrote:
>
> On mardi 18 août 2020 13:52:50 CEST Ben Cooksley wrote:
> > Hi all,
> >
> > At some point recently functionality was added to KIO which broke the
> > build on Android.
>
> Is there any reason why Android doesn't appear at
> https://build.kde.org/job/Frameworks/job/kio/
> ?
>
> This is the reason why I didn't notice this problem.

Because a job hasn't been requested for KIO on Android.

I'm not sure why it is being included in the Dependency Builds /
Docker image builds, as from my understanding Android builds were all
using a cut down list of dependencies.

We can certainly enable Android CI jobs for KIO though, that is easy
enough to do.

Cheers,
Ben

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


Re: KIO on Android Failure

2020-08-19 Thread Ben Cooksley
On Wed, Aug 19, 2020 at 3:01 AM Ahmad Samir  wrote:
>
> On 18/08/2020 13:52, Ben Cooksley wrote:
> > Hi all,
> >
> > At some point recently functionality was added to KIO which broke the
> > build on Android.
> >
> > I'm not sure why we're building KIO on Android, but it appears that
> > some applications may be using it - and this in turn causes the
> > Dependency Build jobs to fail.
> >
> > Could someone take a look please?
> > https://build.kde.org/job/Administration/job/Docker%20Generate%20AndroidQt5.14%20KF5-SDK/lastFailedBuild/console
> >
> > Thanks,
> > Ben
> >
>
> It looks like it's caused by systemd integration in kprocessrunner; also it 
> seems Q_OS_UNIX includes
> Android systems, so we need to guard it with !defind(Q_OS_ANDROID). Should 
> hopefully be fixed by
> https://invent.kde.org/frameworks/kio/-/merge_requests/107 .
>

Many thanks for quickly addressing this Ahmad, it's appreciated.

Cheers,
Ben

> --
> Ahmad Samir


KIO on Android Failure

2020-08-18 Thread Ben Cooksley
Hi all,

At some point recently functionality was added to KIO which broke the
build on Android.

I'm not sure why we're building KIO on Android, but it appears that
some applications may be using it - and this in turn causes the
Dependency Build jobs to fail.

Could someone take a look please?
https://build.kde.org/job/Administration/job/Docker%20Generate%20AndroidQt5.14%20KF5-SDK/lastFailedBuild/console

Thanks,
Ben


Re: Breakage in Breeze Icons

2020-07-22 Thread Ben Cooksley
On Wed, Jul 22, 2020 at 6:49 AM David Redondo  wrote:
>
> I fixed the build now. There was a symlink to a removed file which
> cmake -E copy_directory didn't like.

Thanks for the quick response on this.

>
> Regards,
> David
>
>

Regards,
Ben


Breakage in Breeze Icons

2020-07-21 Thread Ben Cooksley
Hi all,

The build of breeze-icons is currently broken according to the CI system.
Please see https://build.kde.org/view/Failing/job/Frameworks/job/breeze-icons/
for details on this.

This appears to be due to commit 84a9e3953268c499553501a5caafa7ee4f52cc79

Could someone take a look and correct this please?

This is blocking Dependency Builds, which need to be run for Plasma
after KWin started depending immediately on new API in KCModule.

Thanks,
Ben


Re: KDE CI: Frameworks » ktexteditor » kf5-qt5 SUSEQt5.15 - Build # 4 - Still Unstable!

2020-07-11 Thread Ben Cooksley
On Sun, Jul 12, 2020 at 3:23 AM Christoph Cullmann
 wrote:
>
> On 2020-07-09 10:03, Christoph Cullmann wrote:
> > On 2020-07-08 00:07, David Faure wrote:
> >> On mardi 7 juillet 2020 17:58:26 CEST Christoph Cullmann wrote:
> >>> On 2020-07-07 12:16, David Faure wrote:
> >>> > Yep :(
> >>> >
> >>> > You'll tell Simon and/or QTBUG-*?
> >>>
> >>> I will take a look if I can find some existing bug or open a new.
> >>>
> >>> Simon left Qt, or?
> >>
> >> Yes but I think that was already the case when he fixed the last one
> >> :-)
> >
> > I did so some research.
> >
> > Might this be fixed by
> >
> > https://code.qt.io/cgit/qt/qtdeclarative.git/commit/src/qml?h=5.15=082247604219316035484cfdc83662936df2edb5
> >
> > or
> >
> > https://code.qt.io/cgit/qt/qtdeclarative.git/commit/src/qml?h=5.15=082247604219316035484cfdc83662936df2edb5
> >
> > At least the backtraces in the referenced bugs look similar.
> >
> > That isn't in 5.15?
> >
> > Is there a chance to have the CI use some Qt with these backported?
> > (or is it already and it is a different issue?)
>
> I talked with Simon and very likely these commits in the 5.15 branch
> would fix our issues.
>
> Is there a change to get a patched Qt for the CI?

This is not exactly straight forward, but would be possible for Linux at least.
Windows would require they be adopted by Craft, and FreeBSD by the KDE
FreeBSD folks.

>
> If that fixes it, actually, it would be highly important to get these
> fixes in the distro Qt packages,
> otherwise all of KDE that uses the QJSEngine (or QML) will just randomly
> crash.

If SUSE pick up the patches, then the CI system will automatically
pick them up as we use OpenSUSE for the Linux CI images.

>
> Greetings
> Christoph

Regards,
Ben

>
> > Greetings
> > Christoph
>
> --
> Ignorance is bliss...
> https://cullmann.io | https://kate-editor.org


Re: Moving ring-kde to unmaintained (was: Re: Shift for parts of the CI system to Qt 5.15)

2020-07-09 Thread Ben Cooksley
On Sun, Jun 28, 2020 at 9:18 PM Ben Cooksley  wrote:
>
> On Sat, Jun 20, 2020 at 10:40 PM Friedrich W. H. Kossebau
>  wrote:
> >
> > Am Samstag, 20. Juni 2020, 12:25:42 CEST schrieb Ben Cooksley:
> > > On Sat, Jun 20, 2020 at 8:13 PM Volker Krause  wrote:
> > > > On Saturday, 20 June 2020 08:20:18 CEST Ben Cooksley wrote:
> > > > > - ring-kde
> > > >
> > > > build errors seem to be in stuff downloaded by cmake!?
> > >
> > > Indeed, this seems to be a bit concerning.
> > >
> > > I'm wondering if we should discontinue the CI support for this project?
> >
> > Seems ring-kde is unmaintained, it has not seen any development since March
> > 2019, also missed to follow the renaming of GNU Ring to Jami on 18 December
> > 2018 (by what wikipedia tells).
> >
> > So +1 for tagging the repo as unmaintained, and thus also removing from CI.
>
> If nobody has any objections to the above, i'd like to action this in
> 24 hours time.

I've now actioned this.

>
> >
> > Cheers
> > Friedrich
> >
> >
>
> Cheers,
> Ben

Thanks,
Ben


Re: Moving ring-kde to unmaintained (was: Re: Shift for parts of the CI system to Qt 5.15)

2020-06-28 Thread Ben Cooksley
On Sat, Jun 20, 2020 at 10:40 PM Friedrich W. H. Kossebau
 wrote:
>
> Am Samstag, 20. Juni 2020, 12:25:42 CEST schrieb Ben Cooksley:
> > On Sat, Jun 20, 2020 at 8:13 PM Volker Krause  wrote:
> > > On Saturday, 20 June 2020 08:20:18 CEST Ben Cooksley wrote:
> > > > - ring-kde
> > >
> > > build errors seem to be in stuff downloaded by cmake!?
> >
> > Indeed, this seems to be a bit concerning.
> >
> > I'm wondering if we should discontinue the CI support for this project?
>
> Seems ring-kde is unmaintained, it has not seen any development since March
> 2019, also missed to follow the renaming of GNU Ring to Jami on 18 December
> 2018 (by what wikipedia tells).
>
> So +1 for tagging the repo as unmaintained, and thus also removing from CI.

If nobody has any objections to the above, i'd like to action this in
24 hours time.

>
> Cheers
> Friedrich
>
>

Cheers,
Ben


Re: Shift for parts of the CI system to Qt 5.15

2020-06-22 Thread Ben Cooksley
On Mon, Jun 22, 2020 at 9:06 AM David Faure  wrote:
>
> On samedi 20 juin 2020 12:25:42 CEST Ben Cooksley wrote:
> > - ktorrent (when linking with taglib)
>
> Looks like the fix I made to fix ktorrent (failing to link with taglib) also
> fixed the FreeBSD issue you mention.
>
> https://build.kde.org/job/Extragear/job/ktorrent/job/kf5-qt5%20FreeBSDQt5.15/

Thanks for sorting this out David, it's appreciated.

Cheers,
Ben

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


Re: Shift for parts of the CI system to Qt 5.15

2020-06-20 Thread Ben Cooksley
On Sat, Jun 20, 2020 at 8:13 PM Volker Krause  wrote:
>
> On Saturday, 20 June 2020 08:20:18 CEST Ben Cooksley wrote:
> > Hi all,
> >
> > This weekend parts of our CI system shifted to using Qt 5.15, with all
> > FreeBSD builds now being based on Qt 5.15. We also shifted all Linux
> > builds of Plasma, and the latest Qt version build of Frameworks to Qt
> > 5.15 as well (apologies for the massive amount of email this kicked
> > up)
> >
> > It has however exposed a series of SIC changes in Qt which will need
> > to be adapted to. The list of affected projects appears to be as
> > follows:
> > - kalarm
> > - kdesdk-kioslaves
> > - kompare
> > - subtitlecomposer
>
> all fixed
>
> > - kaffeine
>
> This doesn't look like something caused by Qt 5.15, more like an issue with
> the FreeBSD DVB headers, builds on Linux.
>
> > In addition, the following projects appear to have long standing build
> > issues. It would be appreciated if they could please investigate and
> > correct these:
> > - kbibtex
>
> fixed
>
> > - atcore
> > - kmymoney
>
> MSVC-only, or rather GCC/clang being a bit too forgiving.
>
> atcore looks like an ambiguous default argument, removing that should fix it,
> but since this is a public interface I didn't want to just change this, being
> unable to estimate the impact.
>
> kmymoney is using an exported class in two DLLs with the same export macro,
> that doesn't work. Needs more insights into the project to restructure that
> accordingly I think.
>
> > - ring-kde
>
> build errors seem to be in stuff downloaded by cmake!?

Indeed, this seems to be a bit concerning.

I'm wondering if we should discontinue the CI support for this project?

>
> > Further, the following project appears to have a broken build due to
> > SIC changes within another KDE project:
> > - zanshin
>
> fixed

Many thanks for addressing all those various failures Volker, it's appreciated.

One more project I missed from my email, which appears to be a FreeBSD
linking specific issue:
- ktorrent (when linking with taglib)

>
> Regards,
> Volker
>
>
>

Cheers,
Ben


Shift for parts of the CI system to Qt 5.15

2020-06-20 Thread Ben Cooksley
Hi all,

This weekend parts of our CI system shifted to using Qt 5.15, with all
FreeBSD builds now being based on Qt 5.15. We also shifted all Linux
builds of Plasma, and the latest Qt version build of Frameworks to Qt
5.15 as well (apologies for the massive amount of email this kicked
up)

It has however exposed a series of SIC changes in Qt which will need
to be adapted to. The list of affected projects appears to be as
follows:
- kalarm
- kdesdk-kioslaves
- kompare
- kaffeine
- subtitlecomposer

In addition, the following projects appear to have long standing build
issues. It would be appreciated if they could please investigate and
correct these:
- kbibtex
- atcore
- kmymoney
- ring-kde

Further, the following project appears to have a broken build due to
SIC changes within another KDE project:
- zanshin

Cheers,
Ben


[sysadmin/kde-build-metadata] /: KDav wants KIO.

2020-06-19 Thread Ben Cooksley
Git commit 51f12030515eab5f92a4e700708194ac9ee88cfd by Ben Cooksley.
Committed on 19/06/2020 at 20:48.
Pushed by bcooksley into branch 'master'.

KDav wants KIO.

CCMAIL: kde-frameworks-devel@kde.org

M  +1-0dependency-data-kf5-qt5
M  +1-0dependency-data-stable-kf5-qt5

https://invent.kde.org/sysadmin/kde-build-metadata/commit/51f12030515eab5f92a4e700708194ac9ee88cfd

diff --git a/dependency-data-kf5-qt5 b/dependency-data-kf5-qt5
index 7eea764..85c122f 100644
--- a/dependency-data-kf5-qt5
+++ b/dependency-data-kf5-qt5
@@ -100,6 +100,7 @@ frameworks/kconfigwidgets: frameworks/kdoctools
 frameworks/kconfigwidgets: frameworks/kguiaddons
 frameworks/kconfigwidgets: frameworks/ki18n
 frameworks/kconfigwidgets: frameworks/kwidgetsaddons
+frameworks/kdav: frameworks/kio
 frameworks/kdesignerplugin: frameworks/kcoreaddons
 frameworks/kdesignerplugin: frameworks/kconfig
 frameworks/kdesignerplugin: frameworks/kdoctools
diff --git a/dependency-data-stable-kf5-qt5 b/dependency-data-stable-kf5-qt5
index ead579e..650e800 100644
--- a/dependency-data-stable-kf5-qt5
+++ b/dependency-data-stable-kf5-qt5
@@ -100,6 +100,7 @@ frameworks/kconfigwidgets: frameworks/kdoctools
 frameworks/kconfigwidgets: frameworks/kguiaddons
 frameworks/kconfigwidgets: frameworks/ki18n
 frameworks/kconfigwidgets: frameworks/kwidgetsaddons
+frameworks/kdav: frameworks/kio
 frameworks/kdesignerplugin: frameworks/kcoreaddons
 frameworks/kdesignerplugin: frameworks/kconfig
 frameworks/kdesignerplugin: frameworks/kdoctools


[sysadmin/repo-metadata] projects-invent/frameworks/kdav: Reflect move of KDav to Frameworks.

2020-06-19 Thread Ben Cooksley
Git commit 9abbeb9a441afe79a6f96a2fefa61c45655b4e12 by Ben Cooksley.
Committed on 19/06/2020 at 18:17.
Pushed by bcooksley into branch 'master'.

Reflect move of KDav to Frameworks.

Fixes T13301

CCMAIL: kde-frameworks-devel@kde.org

R  +0-0projects-invent/frameworks/kdav/i18n.json [from: 
projects-invent/pim/kdav/i18n.json - 100% similarity]
R  +2-2projects-invent/frameworks/kdav/metadata.yaml [from: 
projects-invent/pim/kdav/metadata.yaml - 066% similarity]

https://invent.kde.org/sysadmin/repo-metadata/commit/9abbeb9a441afe79a6f96a2fefa61c45655b4e12

diff --git a/projects-invent/pim/kdav/i18n.json 
b/projects-invent/frameworks/kdav/i18n.json
similarity index 100%
rename from projects-invent/pim/kdav/i18n.json
rename to projects-invent/frameworks/kdav/i18n.json
diff --git a/projects-invent/pim/kdav/metadata.yaml 
b/projects-invent/frameworks/kdav/metadata.yaml
similarity index 66%
rename from projects-invent/pim/kdav/metadata.yaml
rename to projects-invent/frameworks/kdav/metadata.yaml
index a88dee34..36c7b120 100644
--- a/projects-invent/pim/kdav/metadata.yaml
+++ b/projects-invent/frameworks/kdav/metadata.yaml
@@ -2,6 +2,6 @@ description: DAV protocol implementation with KJobs
 hasrepo: true
 identifier: kdav
 name: KDav
-projectpath: kde/pim/kdav
+projectpath: frameworks/kdav
 repoactive: true
-repopath: pim/kdav
+repopath: frameworks/kdav


Re: New Framework Review: KDAV

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

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

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

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

>
> Thanks,
> Volker

Cheers,
Ben

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

D29810: Don't use the setenv function after fork

2020-06-10 Thread Ben Cooksley
bcooksley added a comment.


  NOTICE OF INTENTION TO REVERT
  
  Due to this commit introducing a FBTFS on FreeBSD, this commit will be 
automatically reverted in 24 hours unless 
https://invent.kde.org/frameworks/kcrash/-/merge_requests/3 has been merged and 
the FTBFS condition corrected.

REPOSITORY
  R285 KCrash

REVISION DETAIL
  https://phabricator.kde.org/D29810

To: jpalecek, #frameworks, dfaure
Cc: bcooksley, ahmadsamir, bruns, apol, anthonyfieroni, kde-frameworks-devel, 
LeGast00n, cblack, michaelh, ngraham


T13144: Remove deprecated code from Kirigami example

2020-05-12 Thread Ben Cooksley
bcooksley added a comment.


  Reassigning from Sysadmin to the Frameworks Developers - we don't maintain 
the API Documentation.

TASK DETAIL
  https://phabricator.kde.org/T13144

To: bcooksley
Cc: bcooksley, kde-frameworks-devel, sanecito, LeGast00n, cblack, michaelh, 
ngraham, bruns


T13144: Remove deprecated code from Kirigami example

2020-05-12 Thread Ben Cooksley
bcooksley edited projects, added Frameworks; removed Sysadmin.
bcooksley edited subscribers, added: kde-frameworks-devel; removed: sysadmin.

TASK DETAIL
  https://phabricator.kde.org/T13144

To: bcooksley
Cc: kde-frameworks-devel, sanecito, sysadmin, duffus


T13144: Remove deprecated code from Kirigami example

2020-05-12 Thread Ben Cooksley
bcooksley changed the visibility from "Custom Policy" to "Public (No Login 
Required)".
bcooksley changed the edit policy from "Custom Policy" to "All Users".

TASK DETAIL
  https://phabricator.kde.org/T13144

To: bcooksley
Cc: kde-frameworks-devel, sanecito, LeGast00n, cblack, michaelh, ngraham, bruns


Fwd: KDE CI: Administration » Dependency Build Calligra stable-kf5-qt5 WindowsMSVCQt5.14 - Build # 24 - Still Failing!

2020-05-10 Thread Ben Cooksley
Can someone investigate the below please?

Thanks,
Ben

-- Forwarded message -
From: CI System 
Date: Sun, May 10, 2020 at 8:01 PM
Subject: KDE CI: Administration » Dependency Build Calligra stable-kf5-qt5
WindowsMSVCQt5.14 - Build # 24 - Still Failing!
To: 


*BUILD FAILURE*
Build URL
https://build.kde.org/job/Administration/job/Dependency%20Build%20Calligra%20stable-kf5-qt5%20WindowsMSVCQt5.14/24/
Project: Dependency Build Calligra stable-kf5-qt5 WindowsMSVCQt5.14
Date of build: Sun, 10 May 2020 07:19:29 +
Build duration: 42 min and counting
* CONSOLE OUTPUT *
[...truncated 43646 lines...]
[2020-05-10T08:00:56.741Z] ]
[2020-05-10T08:00:56.741Z]
C:\Craft\CI-Qt514\windows-msvc2019_64-cl-debug\include\qt5\QtCore\qset.h(251):
note: see declaration of 'QSet::toList'
[2020-05-10T08:00:56.741Z] with
[2020-05-10T08:00:56.741Z] [
[2020-05-10T08:00:56.741Z] T=KFileItem
[2020-05-10T08:00:56.741Z] ]
[2020-05-10T08:00:56.741Z]
C:\Craft\CI-Qt514\windows-msvc2019_64-cl-debug\include\qt5\QtCore\qset.h(405):
note: while compiling class template member function 'QList
QList::fromSet(const QSet &)'
[2020-05-10T08:00:56.741Z] with
[2020-05-10T08:00:56.741Z] [
[2020-05-10T08:00:56.742Z] T=KFileItem
[2020-05-10T08:00:56.742Z] ]
[2020-05-10T08:00:56.742Z] C:\CI\DepBuild\kio\src\core\kfileitem.h(600):
note: see reference to class template instantiation 'QList'
being compiled
[2020-05-10T08:00:56.742Z] [129/731] Building CXX object
src\core\CMakeFiles\KF5KIOCore.dir\kfileitemlistproperties.cpp.obj
[2020-05-10T08:00:57.003Z] [130/731] Building CXX object
src\core\CMakeFiles\KF5KIOCore.dir\mkpathjob.cpp.obj
[2020-05-10T08:00:57.003Z] [131/731] Building CXX object
src\core\CMakeFiles\KF5KIOCore.dir\mkdirjob.cpp.obj
[2020-05-10T08:00:57.003Z] [132/731] Building CXX object
src\core\CMakeFiles\KF5KIOCore.dir\tcpslavebase.cpp.obj
[2020-05-10T08:00:57.270Z] [133/731] Building CXX object
src\core\CMakeFiles\KF5KIOCore.dir\usernotificationhandler.cpp.obj
[2020-05-10T08:00:57.270Z] [134/731] Building CXX object
src\core\CMakeFiles\KF5KIOCore.dir\kfileitem.cpp.obj
[2020-05-10T08:00:57.270Z]
C:\Craft\CI-Qt514\windows-msvc2019_64-cl-debug\include\qt5\QtCore/qset.h(406):
warning C4996: 'QSet::toList': Use values() instead.
[2020-05-10T08:00:57.270Z] with
[2020-05-10T08:00:57.270Z] [
[2020-05-10T08:00:57.270Z] T=KFileItem
[2020-05-10T08:00:57.270Z] ]
[2020-05-10T08:00:57.270Z]
C:\Craft\CI-Qt514\windows-msvc2019_64-cl-debug\include\qt5\QtCore/qset.h(251):
note: see declaration of 'QSet::toList'
[2020-05-10T08:00:57.270Z] with
[2020-05-10T08:00:57.270Z] [
[2020-05-10T08:00:57.270Z] T=KFileItem
[2020-05-10T08:00:57.270Z] ]
[2020-05-10T08:00:57.270Z]
C:\Craft\CI-Qt514\windows-msvc2019_64-cl-debug\include\qt5\QtCore/qset.h(405):
note: while compiling class template member function 'QList
QList::fromSet(const QSet &)'
[2020-05-10T08:00:57.270Z] with
[2020-05-10T08:00:57.270Z] [
[2020-05-10T08:00:57.270Z] T=KFileItem
[2020-05-10T08:00:57.270Z] ]
[2020-05-10T08:00:57.270Z] C:\CI\DepBuild\kio\src\core\kfileitem.h(600):
note: see reference to class template instantiation 'QList'
being compiled
[2020-05-10T08:00:57.880Z] [135/731] Building CXX object
src\core\CMakeFiles\KF5KIOCore.dir\kremoteencoding.cpp.obj
[2020-05-10T08:00:58.146Z] [136/731] Linking CXX executable
bin\httpheaderdispositiontest.exe
[2020-05-10T08:00:58.416Z] [137/731] Linking CXX shared module
bin\kf5\kded\kcookiejar.dll
[2020-05-10T08:00:58.416Z] Creating library lib\kcookiejar.lib and object
lib\kcookiejar.exp
[2020-05-10T08:00:58.416Z] Creating library lib\kcookiejar.lib and object
lib\kcookiejar.exp
[2020-05-10T08:00:58.416Z] [138/731] Building CXX object
src\core\CMakeFiles\KF5KIOCore.dir\knfsshare.cpp.obj
[2020-05-10T08:00:58.416Z] [139/731] Building CXX object
src\core\CMakeFiles\KF5KIOCore.dir\davjob.cpp.obj
[2020-05-10T08:00:58.416Z] [140/731] Building CXX object
src\core\CMakeFiles\KF5KIOCore.dir\filejob.cpp.obj
[2020-05-10T08:00:58.678Z] [141/731] Building CXX object
src\core\CMakeFiles\KF5KIOCore.dir\kdiskfreespaceinfo.cpp.obj
[2020-05-10T08:00:58.678Z] [142/731] Building CXX object
src\core\CMakeFiles\KF5KIOCore.dir\directorysizejob.cpp.obj
[2020-05-10T08:00:58.678Z]
C:\Craft\CI-Qt514\windows-msvc2019_64-cl-debug\include\qt5\QtCore/qset.h(406):
warning C4996: 'QSet::toList': Use values() instead.
[2020-05-10T08:00:58.678Z] with
[2020-05-10T08:00:58.678Z] [
[2020-05-10T08:00:58.678Z] T=KFileItem
[2020-05-10T08:00:58.678Z] ]
[2020-05-10T08:00:58.678Z]
C:\Craft\CI-Qt514\windows-msvc2019_64-cl-debug\include\qt5\QtCore/qset.h(251):
note: see declaration of 'QSet::toList'
[2020-05-10T08:00:58.678Z] with
[2020-05-10T08:00:58.678Z] [
[2020-05-10T08:00:58.678Z] T=KFileItem
[2020-05-10T08:00:58.678Z] ]
[2020-05-10T08:00:58.678Z]
C:\Craft\CI-Qt514\windows-msvc2019_64-cl-debug\include\qt5\QtCore/qset.h(405):
note: while compiling class template member function 'QList
QList::fromSet(const QSet &)'
[2020-05-10T08:00:58.678Z] with
[2020-05-10T08:00:58.678Z] [

Re: Information regarding upcoming Gitlab Migration

2020-05-02 Thread Ben Cooksley
On Sun, May 3, 2020 at 2:13 AM Michał Policht  wrote:
>
> Hi all,

Hi Michal,

>
> Sorry for late response, but project "cutehmi" fits into "sdk" category
> better than "applications" (technically it's a framework, but I guess
> "frameorks" is reserved for well integrated KDE Frameworks).

I have now relocated CuteHMI within the proposed layout to SDK.

The initial allocation to applications/ was done based on it's
position at the moment in playground/base/

>
> Speaking generally on subject, categorization is always problematic.
> Categories often are fuzzy, they overlap, element can match more than
> one type/category/group at the same time and there are many criteria by
> which you could partition a set of elements.
>
> Maybe for future reference, it would be good if there was some
> explanation on how these groups are created. From what I can see large
> projects organized into subprojects have dedicated groups (e.g. plasma,
> kdevelop). There are groups based on project status (e.g. unmaintained,
> historical). Then we have a division, which seems to be based on use
> case from development applicability perspective (e.g. libraries,
> frameworks, sdk). Then we have applications divided into something like
> user interests (e.g. multimedia, games, office, education). Since you
> mention that project may belong to many groups it would be nice to
> clarify, if for example game-oriented library (which occupies
> "libraries") fits into "games" group as well or is "games" group
> reserved for end-user applications only.

There are no hard and fast rules for categorisation.

Libraries that are only suitable for a specific purpose (like Games)
could certainly go in Games.
In general we'd expect maintainers to indicate a preference when
requesting repositories.

>
> Regards
> Michał

Cheers,
Ben

>
>
> On 4/27/20 3:40 AM, Bhushan Shah wrote:
> > [Please keep sysad...@kde.org list or bs...@kde.org in the CC for
> > replies]
> >
> > Hello Community members,
> >
> > In view of upcoming Gitlab migration, we sysadmin team wants to share
> > the recommended structuring for the repositories on Gitlab.
> >
> > We had multiple options,
> >
> > - Flat structure: In this option we would have everything under one
> >single namespace/group: https://invent.kde.org/kde/knetwalk
> > - Subgroups under top-level group: In this option we would have a groups
> >under KDE namespace: https://invent.kde.org/kde/games/knetwalk
> > - Groups at top level: In this option we would establish a series of
> >groups at the top level, e.g.  https://invent.kde.org/games/knetwalk
> >
> > We have discussed this with small but representative group of
> > contributors or maintainers, and based on their suggestions, we
> > recommend that we go with option 3. Having sub-groups at top level will
> > allow us to,
> >
> > - Provides good visibility on all reviews, tasks and other items within
> >the groups/modules we define
> > - Provides improvements to discoverability of projects
> > - Makes it possible for groups of projects to establish a group level
> >task board should it fit their needs (for tracking a release for
> >instance)
> > - Makes the most semantic sense, as the ‘KDE’ top level group suggested
> >in option 2 is duplicative considering the Gitlab instance is under
> >kde.org.
> > - The discoverability of projects is maximised, as there is no need to
> >open the top level ‘KDE’ group before going into the subgroup.
> >
> > I've worked on draft "move" of the current set of the repositories in
> > their respective subgroups at the repo-metadata project's branch [1].
> > You can browse the directory structure to get idea of how final
> > structure on Gitlab would look like.
> >
> > If we don't have any objections we would like to implement this next
> > week and move projects to https://invent.kde.org.
> >
> > Thanks!
> > Bhushan for sysadmin team
> >
> > [1] 
> > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
> >
>


Re: Information regarding upcoming Gitlab Migration

2020-05-01 Thread Ben Cooksley
On Sat, May 2, 2020 at 9:04 AM Nate Graham  wrote:
>
> On 5/1/20 2:09 PM, Ben Cooksley wrote:
> > Unfortunately sharing of projects/repositories across groups does not
> > impact on tasks and reviews.
> > This means that merge requests for Planet (which is currently shared
> > with "KDE") do not show up in the list of merge requests for "KDE".
> >
> > Sharing repositories allows for a global listing only.
> Are you saying that if we put plasma-framework in Plasma and share it
> with the Plasma group, then its MRs won't show up in the Plasma group's
> MR list? And that if we put it in the Plasma group and share it with the
> Frameworks group, then its MRs won't show up in the Frameworks group's
> MR list?

That is correct.

>
> If so, that seems like it defeats one of the points of sharing a
> project/repo across groups. :(
>
> Is this fixed in EE, or is it just a bug affecting all versions?

It affects all versions.

>
> Nate

Regards,
Ben


Re: Information regarding upcoming Gitlab Migration

2020-05-01 Thread Ben Cooksley
On Sat, May 2, 2020 at 6:17 AM Alexander Potashev  wrote:
>
> On Tue, Apr 28, 2020 at 6:47 AM Bhushan Shah  wrote:
> > Use case 4 : Tom is a student in Germany and is interested in
> > contributing to wikitolearn, and he asks where can I find code of the
> > wikitolearn?
>
> Hi,

Hi Alexander,

>
> I have a similar use case. Sometimes I need to share a URL to a
> project. For this purpose I used to share e.g.
> https://cgit.kde.org/releaseme.git/about
>
> Does this migration make such permalinks impossible?
>
>
> From what I see, we lose permalinks because
>  1. cgit.kde.org will be discontinued

We provide the commits.kde.org redirector for permanent links.
Anywhere needing a long life link to a particular repository, commit,
etc (like documentation) should be using these links and not anything
else.

>  2. A once valid URL https://invent.kde.org/games/knetwalk may become
> unavailable if the project moves to another group, for example
> https://invent.kde.org/unmaintained/knetwalk
>

As mentioned by Nicolas, Gitlab maintains redirects so if such a move
were to take place, the above links would continue to work.
The only time this is not the case is when a new repository takes it's place.

> --
> Alexander Potashev

Cheers,
Ben


Re: Information regarding upcoming Gitlab Migration

2020-05-01 Thread Ben Cooksley
On Sat, May 2, 2020 at 2:33 AM Adriaan de Groot  wrote:
>
> On 2020 mayula d. 1id 07:08:41 CEST Ben Cooksley wrote:
> > On Fri, May 1, 2020 at 2:46 AM Nate Graham  wrote:
> > > If I'm understanding things, we have solutions to most or all of the
> > > objections raised so far:
> > >
> > > - Projects will be allowed to live in--or at least appear in--multiple
> > > top-level groups (e.g. plasma-framework could appear in both the
> > > Frameworks top-level group and also the Plasma top-level group)
> >
> > Projects will have the option to appear in multiple groups yes.
>
> Forgive me for coming full circle on this discussion, but
>
> - a group can have at most one workboard
> - a group offers some facilities for managing issues and reviews that cross
> over repositories within that group
> - a project (this is one-to-one with "repository", right?) can have as many
> workboards as it likes

Correct. Projects and repositories are the same thing, it is just a
matter of terminology.

>
> If a project can appear in more than one group, isn't the whole distinction
> between flat and namespaced a little ..

The ability for a project to appear in other groups is subject to some
limitations.
See https://invent.kde.org/groups/kde/-/shared for a list of
repositories currently shared with "KDE"

>
> well, how would this proposal fly?
>
> - Put everything in a single group called "kde" (this matches proposal 2 if I
> still remember the original numbering right -- flat, but not at top-level)

Proposal 2 had the groupings within a larger "KDE" group, rather than
at top level.

Proposal 1 was fully flat, just dump everything in one group.

> - Other groups hold things from "kde" (this matches proposal 3, giving more
> structure / hierarchy)
>
> People browsing *top* level would see group "kde" (for all I care, bookmark
> that one as "I want to browse the list of 1442 repositories") and a bunch of
> logical groups based on how the community organizes itself. People working
> inside a specific group can do their workboardy-things and focus on the
> repositories for that group, while people with an overall interest go to the
> KDE group.
>

Unfortunately sharing of projects/repositories across groups does not
impact on tasks and reviews.
This means that merge requests for Planet (which is currently shared
with "KDE") do not show up in the list of merge requests for "KDE".

Sharing repositories allows for a global listing only.

>
>
> Somehow I get the feeling that we started with some technical limitations
> which were driving particular choices, where those limitations aren't exactly
> what we assumed that they were, and now it looks to me like those limitations
> do not have to meaningfully impact *any* of the choices.
>
> (*if* my understanding is correct; I've been wrong enough times already today)
>
> [ade]

Cheers,
Ben


Re: Information regarding upcoming Gitlab Migration: clarifications

2020-04-30 Thread Ben Cooksley
On Fri, May 1, 2020 at 4:38 PM Nate Graham  wrote:
>
>
>
> On 4/30/20 5:59 PM, Aleix Pol wrote:
> > El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid
> >> Am I the only person that just has all the repos on the same folder? I 
> >> thought it was the common thing to do :?
> >
> > I do too
>
> Same here. kdesrc-build's default settings do this, and download all
> repos into ~/kde/src without any of the levels of hierarchy. This would
> seem to require unique repo names, no?

Not necessarily.

Git allows you to override the name that the local folder is called
when cloning, so there is no reason why we can't specify something in
the metadata to override the local name that the folder gets called in
your local checkout folder.
This would allow for example:

- frameworks/kcoreaddons on Gitlab continues to be called
'kcoreaddons' in your local checkout folder
- maui/dialer on Gitlab gets called 'maui-dialer' in your local checkout folder

This allows for the URLs on Gitlab to make sense, while simultaneously
allowing your local source checkout folders to continue to work in the
manner in which they do currently.
Note that we do not expect people to hit this in many cases - this is
about giving us the flexibility for the long term without imposing
unnecessary bureaucracy and limits on projects within the KDE
umbrella.

Automated tooling such as kdesrc-build and the proposed clone script
(that searches in namespaces) should be able to handle this without
much issue.
In the case of manually done clones, it is reasonable to expect people
to know what they're doing with their clones, and name them
appropriately in the event they have a collision.

Does this sound acceptable?

>
> The group categorization we've been discussing may be useful on the web
> UI for newcomers, but it has no value for your source checkout folder
> IMO, where it just makes it slightly more annoying to navigate from one
> repo to another.
>
> Nate

Cheers,
Ben


Re: Information regarding upcoming Gitlab Migration

2020-04-30 Thread Ben Cooksley
On Fri, May 1, 2020 at 2:46 AM Nate Graham  wrote:
>
> If I'm understanding things, we have solutions to most or all of the
> objections raised so far:
>
> - Projects will be allowed to live in--or at least appear in--multiple
> top-level groups (e.g. plasma-framework could appear in both the
> Frameworks top-level group and also the Plasma top-level group)

Projects will have the option to appear in multiple groups yes.

>
> - kdesrc-build and other scripts can be updated to allow people to
> easily check out repos using git prefixes (e.g. so that something like
> `git clone kde:dolphin` will still work regardlyss of a project's
> underlying group)

The syntax will probably be slightly different to that, but the
concept is correct yes.

>
> - cgit will continue to exist for three weeks to provide some transition
> time

Correct.

>
> - Each repo can have its own workboard in addition to the single
> group-level workboard

Correct, just one small clarification: each project (repository) can
have multiple workboards, there is no limit to this.
Groups are limited to a single workboard.

>
> If the above are accurate, then I firmly support the proposal.
>
> As for the actual grouping, I think it makes sense to have top-level
> groups for Frameworks, Plasma, PIM, etc. as originally proposed. I can
> support putting apps into category-specific groups (e.g. Multimedia,
> Office, Graphics, Games, etc) as long as apps could appear in multiple
> groups if needed for the case of apps that logically span boundaries
> (e.g. repos for PlaMo apps could appear in both the Plasma Mobile
> top-level group and also the relevant app group).
>
>
> Nate

Cheers,
Ben


Re: Information regarding upcoming Gitlab Migration: clarifications

2020-04-30 Thread Ben Cooksley
On Fri, May 1, 2020 at 5:58 AM Nate Graham  wrote:
>
>
>
> On 4/30/20 11:43 AM, Aleix Pol wrote:
> > IMHO needing tools ad-hoc to KDE development can be a barrier of entrance.
> > I feel like these things make us look distant, it's important that
> > people's skills translate automatically when they want to get started.
>
> True, but if you're a new contributor, presumably our infrastructure
> would do the right thing the first time and you wouldn't need to use any
> migration script, right?

That is correct.

>
> Nate

Cheers,
Ben


Re: Information regarding upcoming Gitlab Migration: clarifications

2020-04-30 Thread Ben Cooksley
On Fri, May 1, 2020 at 6:04 AM Ivan Čukić  wrote:
>
> > We have made a big fuss in the past about having different projects
> > that do the same thing and now we'll have that but also we'll have
> > several projects with the same name?
> > It really feels off to me and I wonder if this is related to the move to
> > gitlab.
>
> +1 to both sentiments - that projects should have different names and that
> this is a bit off topic for the gitlab migration.

The projects *DO* have very different names. That *HAS NOT* changed.
To use the example Bhushan gave above, one is called Plasma Mobile
Dialer and the other one is called Maui Dialer.

With the current git.kde.org setup, we have a flat namespace, so all
repositories if the name appears to be generic (as dialer is) have to
be namespaced by prefixing of the repository name.

With Gitlab however we will now namespaces that group repositories,
making the prefixing unnecessary and as some projects have complained
about, duplicative.

Otherwise you end up with plasma-mobile/plasma-mobile-dialer as your
path, which just looks silly.

>
> Cheers,
> Ivan
>
>

Regards,
Ben

>
> --
> dr Ivan Čukić
> i...@cukic.co, https://cukic.co/
> gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232  07AE 01C6 CE2B FF04 1C12
>
>


Re: Information regarding upcoming Gitlab Migration: clarifications

2020-04-30 Thread Ben Cooksley
On Fri, May 1, 2020 at 5:44 AM Aleix Pol  wrote:
>
> On Wed, Apr 29, 2020 at 12:25 PM Bhushan Shah  wrote:
> >
> > Good afternoon,
> >
> > [Please keep sysad...@kde.org list or bs...@kde.org in the CC for
> > replies]
> >
> > I want to clarify some bits for which we have gotten a questions about,
> >
> > - Non unique naming: There's some teams which prefer if we dropped the
> >   namespace- part from their name which we have added. While currently
> >   this does not result in the naming conflict right away, we realize
> >   this will cause it at one point, for example,
> >
> >   maui-dialer -> maui/dialer
> >   plasma-dialer -> plasma-mobile/dialer
> >
> >   To minimize the impact of the Gitlab move we won't be doing such
> >   renames which introduce non-unique names right away. But we would
> >   prefer if the existing tooling or infrastructure is ready for this
> >   kind of cases at later point. Only way to enforce non-unique naming is
> >   one big KDE/ subgroup which we want to avoid.
> >
> >   Current naming in the repo-metadata branch[1] I've pointed does not
> >   reflect those renames, as we are not planning to do those renames
> >   right away during gitlab move, but at a later stage.
>
> We have made a big fuss in the past about having different projects
> that do the same thing and now we'll have that but also we'll have
> several projects with the same name?
> It really feels off to me and I wonder if this is related to the move to 
> gitlab.
>
> > - Existing configurations: we want to reduce impact on existing release
> >   schedule, and existing developer workflow,  therefore we will continue
> >   to privide the existing anongit.kde.org and git.kde.org (although this
> >   will be read-only) with current flat structuring for 3 weeks after
> >   actual migration, which will keep the existing scripts/clones working
> >   enough to give developers time to change to the new structure.
> >
> >   We will also try to provide a script which allows you to migrate your
> >   existing clones to new repo paths and as mentioned by Ben in other
> >   message, potentially a git-kde script which would allow you to clone
> >   individual repository without knowing it's namespace (provided that
> >   there is no conflict of it's name). like "git kde karchive"
>
> IMHO needing tools ad-hoc to KDE development can be a barrier of entrance.
> I feel like these things make us look distant, it's important that
> people's skills translate automatically when they want to get started.

These tools are being provided as migration assistants.

New contributors won't have a problem, as they'll be used to finding
the project at games/knetwalk (to use an example).

>
> > - Translations: we will co-ordinate with the translations team to let
> >   them adapt their tooling to updated structure as this requires changes
> >   on their side how translations are stored in svn repository
>
> Thanks! :)

Cheers,
Ben


Re: Information regarding upcoming Gitlab Migration

2020-04-28 Thread Ben Cooksley
On Tue, Apr 28, 2020 at 11:09 PM Adriaan de Groot  wrote:
>
> There are a whole bunch of considerations and use-cases being discussed at
> once in this thread, and Leinir's post made me think a bit about different
> actors can interact with "the collection of repositories".
>
> One actor is "tooling", as Albert has pointed out. Whatever the resulting
> structure is, it needs to be communicated to tool authors on time for tools to
> be updated, released, and rolled out for use. Tools mentioned so far:
>  - kdesrc-build
>  - i18n / scripty
>  - release scripts
> The tools don't have An Opinion regarding the layout, they just need to be
> updated.
>
> A tool-like actor that I don't think has been mentioned so far is "existing
> checkouts". I have a src/kde with all the bits I've looked at "recently".
> There may even be some SVN checkouts there -- I'm willing to forget about
> those. Surprising and annoying me every time I update those sometime in the
> future is not good, but it's only going to annoy me once (per repo, so at most
> 143 times for my clones).
>
> I'd be *vaguely* worried about existing crontabs and automatic jobs that we've
> forgotten about, or which others have forgotten about. Those aren't fixable in
> the face of any changes to repositories, anyway.
>
>
> Turning to human actors, who are the more interesting ones,
>
> On 2020 prilula d. 28id 10:38:36 CEST Dan Leinir Turthra Jensen wrote:
> > On Monday, 27 April 2020 21:25:09 BST Albert Astals Cid wrote:
> > > El dilluns, 27 d’abril de 2020, a les 13:58:02 CEST, Bhushan Shah va
> > > > On Mon, Apr 27, 2020 at 12:38:42PM +0200, Aleix Pol wrote:
> > > > > Does this mean that to clone it we'll have to go "git clone
> > > > > kde:games/knetwalk" or something along the lines?
>
> > > > > If that's the case I'd much prefer if we didn't do this, at the moment
> > > > > it's already uncomfortable for me to remember the URL for some of the
> > > > > repos (e.g. is it sysadmin/ or not?), this will only increase the
> > > > > problem and I personally don't see the advantage.
>
>
> Humans come in all shapes and sizes; here's one called Aleix who likes to
> remember the name of a thing, one single label. (Ironic: this particular Aleix
> is also labelled "Aleix Pol" and possibly "Aleix Pol Gonzales") The question
> I'd ask is "in what **context** do you need to remember the URL of a repo?"
> and for that matter: "why is 'knetwalk' an obvious thing to remember, and
> 'games/knetwalk' not-obvious?"
>
> Context here can mean many things. In this thread we've had mentioned:
>  - people just browsing and wanting A Big List
>Here a hierarchical approach means more clicks and navigating a tree,
>rather than a flat structure.
>  - people browsing for a known label
>Using ^F in a flat list or some search field (see also Ian Wadham's
>message just now) doesn't seem *that* different to me, although I've
>got to give ^F the benefit of speed and simplicity.
>  - developers sharing a task list and reviews
>
> .. probably more. Some of these roles have, depending on the chosen solution,
> problems that can be solved with a *technical* addition
> (bigflatlistofrepositories.kde.org .. or whatever), others are going to need a
> social solution.
>
>
>
> Personally, I'm with Leinir here:
>
> > Just adding my "i don't use kdesrc-build, and git clone kde:x everything
> > myself" voice, here.
>
> Perhaps it's the "old school", but kdesrc-build doesn't do anything for me.
> I'm intermittently interested in the source of some random part of KDE --
> generally because it's mentioned on IRC -- and then I need that source where I
> can look at it. Whether it's 'git clone' or 'kdesrc-build --just-the-source-
> please' doesn't matter much.
>
> If there's any compiling to be done, the less magic there is between me and
> the compile, the better.
>
> So, yeah: `git clone kde:x` all the way, but I'm also not really invested in
> the structure of the label x, or the precise configuration of kde:.
>
>
> > Now, if a simple(ish) script can be created to make
> > something akin to the kde: rewriting work, even if what it really does is to
> > search gitlab and create a clone with the appropriate command, i could deal
> > with that, but having the ability to simply ask for the project name is
> > more than a little useful.
>
> I think we shouldn't underestimate how names are a social construct, though:
> the current flat structure comes after a structured SVN naming epoch. But I'd
> totes +1 a search-and-redirector, especially if it means I can write `git
> clone kde:peruse` and the resulting .git/config has followed the redirects and
> whatnot and ended up with `url: kdeforreal:audio/peruse`

Would some form of git alias/custom command script that works similar
to the following be suitable?

git kde-clone skrooge

That script would then search the appropriate groups (ignoring any
personal repositories including forks), find the necessary repository
and perform the clone 

Re: Information regarding upcoming Gitlab Migration

2020-04-27 Thread Ben Cooksley
On Tue, Apr 28, 2020 at 8:31 AM Albert Astals Cid  wrote:
>
> El dilluns, 27 d’abril de 2020, a les 13:19:07 CEST, Ben Cooksley va escriure:
> > On Mon, Apr 27, 2020 at 11:12 PM Olivier Churlaud  
> > wrote:
> > >
> > > Hi,
> > >
> > > Le lundi 27 avril 2020, 12:38:42 CEST Aleix Pol a écrit :
> > > > On Mon, Apr 27, 2020 at 3:41 AM Bhushan Shah  wrote:
> > > > >
> > > > > [Please keep sysad...@kde.org list or bs...@kde.org in the CC for
> > > > > replies]
> > > > >
> > > > > Hello Community members,
> > > > >
> > > > > In view of upcoming Gitlab migration, we sysadmin team wants to share
> > > > > the recommended structuring for the repositories on Gitlab.
> > > > >
> > > > > We had multiple options,
> > > > >
> > > > > - Flat structure: In this option we would have everything under one
> > > > > single namespace/group: https://invent.kde.org/kde/knetwalk
> > > > > - Subgroups under top-level group: In this option we would have a 
> > > > > groups
> > > > > under KDE namespace: https://invent.kde.org/kde/games/knetwalk
> > > > > - Groups at top level: In this option we would establish a series of
> > > > > groups at the top level, e.g.  https://invent.kde.org/games/knetwalk
> > > > >
> > >
> > > Thank you for having options and talking to us before implementing it.
> > >
> > > > > We have discussed this with small but representative group of
> > > > > contributors or maintainers, and based on their suggestions, we
> > > > > recommend that we go with option 3. Having sub-groups at top level 
> > > > > will
> > > > > allow us to,
> > > > >
> > > > > - Provides good visibility on all reviews, tasks and other items 
> > > > > within
> > > > > the groups/modules we define
> > > > > - Provides improvements to discoverability of projects
> > > > > - Makes it possible for groups of projects to establish a group level
> > > > > task board should it fit their needs (for tracking a release for
> > > > > instance)
> > > > > - Makes the most semantic sense, as the ‘KDE’ top level group 
> > > > > suggested
> > > > > in option 2 is duplicative considering the Gitlab instance is under
> > > > > kde.org.
> > > > > - The discoverability of projects is maximised, as there is no need to
> > > > > open the top level ‘KDE’ group before going into the subgroup.
> > > > >
> > > > > I've worked on draft "move" of the current set of the repositories in
> > > > > their respective subgroups at the repo-metadata project's branch [1].
> > > > > You can browse the directory structure to get idea of how final
> > > > > structure on Gitlab would look like.
> > > > >
> > > > > If we don't have any objections we would like to implement this next
> > > > > week and move projects to https://invent.kde.org.
> > > > >
> > > > > Thanks!
> > > > > Bhushan for sysadmin team
> > > > >
> > > > > [1] 
> > > > > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
> > > >
> > > > Does this mean that to clone it we'll have to go "git clone
> > > > kde:games/knetwalk" or something along the lines?
> > > >
> > > > If that's the case I'd much prefer if we didn't do this, at the moment
> > > > it's already uncomfortable for me to remember the URL for some of the
> > > > repos (e.g. is it sysadmin/ or not?), this will only increase the
> > > > problem and I personally don't see the advantage.
> > > >
> > > > e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
> > > > krita graphics or its own thing?
> > > >
> > > > I really prefer when I don't have to guess this kind of things when
> > > > fetching a repository.
> > > >
> > >
> > > I 100% agree with Aleix and I think it would also be detrimental for 
> > > discoverability, exactly for the examples Aleix just gave.
> > >
> > > We came back from this subgroups ideas some times ago : wiki pages were 
> > > hard to find because hidden under layers of grou

Re: Information regarding upcoming Gitlab Migration

2020-04-27 Thread Ben Cooksley
On Tue, Apr 28, 2020 at 1:46 AM Nate Graham  wrote:
>
>
>
> On 4/27/20 4:38 AM, Aleix Pol wrote:
> > Does this mean that to clone it we'll have to go "git clone
> > kde:games/knetwalk" or something along the lines?
> >
> > If that's the case I'd much prefer if we didn't do this, at the moment
> > it's already uncomfortable for me to remember the URL for some of the
> > repos (e.g. is it sysadmin/ or not?), this will only increase the
> > problem and I personally don't see the advantage.
> >
> > e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
> > krita graphics or its own thing?
>
> Trying to categorize everything into a single group cannot succeed
> because many projects could logically belong to multiple groups (e.g
> plasma-framework is a framework that's a part of Plasma; Discover is an
> app that's a part of Plasma; kdenetwork-filesharing and kio-extras are
> libraries that are distributed via the apps release service). I foresee
> endless pointless arguments about the best group for something to live in.

Sorry, but I don't think that will be a problem in reality.
Historically, back in the Subversion era, we had no choice but to
assign things to modules
(multimedia/graphics/office/network/games/etc) and we made that work
without much in the way of problems.

>
> Let's step back: do we have to put every repo inside a group in the
> first place? Is it solely so you can look at a nice list of all open
> merge requests for PIM/Frameworks/etc? If so, perhaps this workflow
> could be approximated with tags instead or group assignments instead

Given the complaints we have had around Phabricator, I can assure you
that tags/labels will not work.

People won't understand them, and we will have discoverability issues
with them especially for newcomers.

>
> We create many very granular groups for the purposes of organizing teams
> and and performing code review (e.g. Plasma, KWin, Frameworks, PIM,
> Krita, Dolphin, Okular, VDG, etc.) and then every new merge request
> could receive a tag or assignee corresponding to its relevant code
> review groups (e.g. merge requests for kio and kio-extras could get get
> tagged with both "Frameworks", and "Dolphin"; plasma-frameworks MRs
> could get tagged with both "Plasma" and "Frameworks", and so on).
>
> So +1 for a single top-level group I suppose.
>
> Nate

Regards,
Ben


Re: Information regarding upcoming Gitlab Migration

2020-04-27 Thread Ben Cooksley
On Mon, Apr 27, 2020 at 11:12 PM Olivier Churlaud  wrote:
>
> Hi,
>
> Le lundi 27 avril 2020, 12:38:42 CEST Aleix Pol a écrit :
> > On Mon, Apr 27, 2020 at 3:41 AM Bhushan Shah  wrote:
> > >
> > > [Please keep sysad...@kde.org list or bs...@kde.org in the CC for
> > > replies]
> > >
> > > Hello Community members,
> > >
> > > In view of upcoming Gitlab migration, we sysadmin team wants to share
> > > the recommended structuring for the repositories on Gitlab.
> > >
> > > We had multiple options,
> > >
> > > - Flat structure: In this option we would have everything under one
> > > single namespace/group: https://invent.kde.org/kde/knetwalk
> > > - Subgroups under top-level group: In this option we would have a groups
> > > under KDE namespace: https://invent.kde.org/kde/games/knetwalk
> > > - Groups at top level: In this option we would establish a series of
> > > groups at the top level, e.g.  https://invent.kde.org/games/knetwalk
> > >
>
> Thank you for having options and talking to us before implementing it.
>
> > > We have discussed this with small but representative group of
> > > contributors or maintainers, and based on their suggestions, we
> > > recommend that we go with option 3. Having sub-groups at top level will
> > > allow us to,
> > >
> > > - Provides good visibility on all reviews, tasks and other items within
> > > the groups/modules we define
> > > - Provides improvements to discoverability of projects
> > > - Makes it possible for groups of projects to establish a group level
> > > task board should it fit their needs (for tracking a release for
> > > instance)
> > > - Makes the most semantic sense, as the ‘KDE’ top level group suggested
> > > in option 2 is duplicative considering the Gitlab instance is under
> > > kde.org.
> > > - The discoverability of projects is maximised, as there is no need to
> > > open the top level ‘KDE’ group before going into the subgroup.
> > >
> > > I've worked on draft "move" of the current set of the repositories in
> > > their respective subgroups at the repo-metadata project's branch [1].
> > > You can browse the directory structure to get idea of how final
> > > structure on Gitlab would look like.
> > >
> > > If we don't have any objections we would like to implement this next
> > > week and move projects to https://invent.kde.org.
> > >
> > > Thanks!
> > > Bhushan for sysadmin team
> > >
> > > [1] 
> > > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
> >
> > Does this mean that to clone it we'll have to go "git clone
> > kde:games/knetwalk" or something along the lines?
> >
> > If that's the case I'd much prefer if we didn't do this, at the moment
> > it's already uncomfortable for me to remember the URL for some of the
> > repos (e.g. is it sysadmin/ or not?), this will only increase the
> > problem and I personally don't see the advantage.
> >
> > e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
> > krita graphics or its own thing?
> >
> > I really prefer when I don't have to guess this kind of things when
> > fetching a repository.
> >
>
> I 100% agree with Aleix and I think it would also be detrimental for 
> discoverability, exactly for the examples Aleix just gave.
>
> We came back from this subgroups ideas some times ago : wiki pages were hard 
> to find because hidden under layers of groups. The same was true for api 
> documentations. Now everything is flat and I think it's easier to find.
>
> Another bad message could also be sent by this: instead of exposing Konsole 
> or Ark as two applications under the KDE umbrella, it would look like Utils 
> for KDE, bringing back the KDE Desktop idea (where every application is 
> already store in a submenu).
>
> As someone wrote later, if I'm looking for a given application, there is 
> always the search function...

That requires that you know it exists. We have 1,043 mainline
repositories at the moment, which translates to 53 pages of projects
under a flat structure system.
Reality is nobody is going to page through that looking for something.

Please also see my point regarding listing merge requests at the group
level - you can see an example of what a flat structure ends up
looking like at https://gitlab.gnome.org/GNOME

For those projects that span multiple repositories, you have just
denied them any chance or ability to see a listing of everything
related to their wider project.

>
> Best regards,
> Olivier
> > Aleix
>
>

Cheers,
Ben


Re: Information regarding upcoming Gitlab Migration

2020-04-27 Thread Ben Cooksley
On Mon, Apr 27, 2020 at 10:50 PM Piyush Aggarwal
 wrote:
>
>
>
> On Mon, 27 Apr, 2020, 4:09 pm Aleix Pol,  wrote:
>>
>> On Mon, Apr 27, 2020 at 3:41 AM Bhushan Shah  wrote:
>> >
>> > [Please keep sysad...@kde.org list or bs...@kde.org in the CC for
>> > replies]
>> >
>> > Hello Community members,
>> >
>> > In view of upcoming Gitlab migration, we sysadmin team wants to share
>> > the recommended structuring for the repositories on Gitlab.
>> >
>> > We had multiple options,
>> >
>> > - Flat structure: In this option we would have everything under one
>> >   single namespace/group: https://invent.kde.org/kde/knetwalk
>> > - Subgroups under top-level group: In this option we would have a groups
>> >   under KDE namespace: https://invent.kde.org/kde/games/knetwalk
>> > - Groups at top level: In this option we would establish a series of
>> >   groups at the top level, e.g.  https://invent.kde.org/games/knetwalk
>> >
>> > We have discussed this with small but representative group of
>> > contributors or maintainers, and based on their suggestions, we
>> > recommend that we go with option 3. Having sub-groups at top level will
>> > allow us to,
>> >
>> > - Provides good visibility on all reviews, tasks and other items within
>> >   the groups/modules we define
>> > - Provides improvements to discoverability of projects
>> > - Makes it possible for groups of projects to establish a group level
>> >   task board should it fit their needs (for tracking a release for
>> >   instance)
>> > - Makes the most semantic sense, as the ‘KDE’ top level group suggested
>> >   in option 2 is duplicative considering the Gitlab instance is under
>> >   kde.org.
>> > - The discoverability of projects is maximised, as there is no need to
>> >   open the top level ‘KDE’ group before going into the subgroup.
>> >
>> > I've worked on draft "move" of the current set of the repositories in
>> > their respective subgroups at the repo-metadata project's branch [1].
>> > You can browse the directory structure to get idea of how final
>> > structure on Gitlab would look like.
>> >
>> > If we don't have any objections we would like to implement this next
>> > week and move projects to https://invent.kde.org.
>> >
>> > Thanks!
>> > Bhushan for sysadmin team
>> >
>> > [1] 
>> > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
>>
>> Does this mean that to clone it we'll have to go "git clone
>> kde:games/knetwalk" or something along the lines?
>>
>> If that's the case I'd much prefer if we didn't do this, at the moment
>> it's already uncomfortable for me to remember the URL for some of the
>> repos (e.g. is it sysadmin/ or not?), this will only increase the
>> problem and I personally don't see the advantage.
>>
>> e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
>> krita graphics or its own thing?
>>
>> I really prefer when I don't have to guess this kind of things when
>> fetching a repository.
>>
>> Aleix
>
>
> This is technical so I would love to hear Sysadmin team's thoughts on this: 
> Probably there can be a redirect system that lets us do git clone 
> kde:knotifications and manages to redirect it to 
> kde/frameworks/tier3/knotifications.git
> So we can clone and tinker with stuff as we normally do while the sysadmin 
> team goes with the recommended system of setting up the repos.
> I think this should be possible because Invent already redirects my URLs 
> which don't end with .git to .git ones. I might be wrong about my assumption 
> that both things can work similarly.

That would require modifications to Gitlab, which may not even be
technically possible.
It is likely a rewrite script will be provided to smooth the transition.

Please note that knotifications would go to
https://invent.kde.org/frameworks/knotifications under this proposal,
not the longer path you've referred to above.

>
> Best
> Piyush Aggarwal

Cheers,
Ben


Re: Information regarding upcoming Gitlab Migration

2020-04-27 Thread Ben Cooksley
On Mon, Apr 27, 2020 at 10:39 PM Aleix Pol  wrote:
>
> On Mon, Apr 27, 2020 at 3:41 AM Bhushan Shah  wrote:
> >
> > [Please keep sysad...@kde.org list or bs...@kde.org in the CC for
> > replies]
> >
> > Hello Community members,
> >
> > In view of upcoming Gitlab migration, we sysadmin team wants to share
> > the recommended structuring for the repositories on Gitlab.
> >
> > We had multiple options,
> >
> > - Flat structure: In this option we would have everything under one
> >   single namespace/group: https://invent.kde.org/kde/knetwalk
> > - Subgroups under top-level group: In this option we would have a groups
> >   under KDE namespace: https://invent.kde.org/kde/games/knetwalk
> > - Groups at top level: In this option we would establish a series of
> >   groups at the top level, e.g.  https://invent.kde.org/games/knetwalk
> >
> > We have discussed this with small but representative group of
> > contributors or maintainers, and based on their suggestions, we
> > recommend that we go with option 3. Having sub-groups at top level will
> > allow us to,
> >
> > - Provides good visibility on all reviews, tasks and other items within
> >   the groups/modules we define
> > - Provides improvements to discoverability of projects
> > - Makes it possible for groups of projects to establish a group level
> >   task board should it fit their needs (for tracking a release for
> >   instance)
> > - Makes the most semantic sense, as the ‘KDE’ top level group suggested
> >   in option 2 is duplicative considering the Gitlab instance is under
> >   kde.org.
> > - The discoverability of projects is maximised, as there is no need to
> >   open the top level ‘KDE’ group before going into the subgroup.
> >
> > I've worked on draft "move" of the current set of the repositories in
> > their respective subgroups at the repo-metadata project's branch [1].
> > You can browse the directory structure to get idea of how final
> > structure on Gitlab would look like.
> >
> > If we don't have any objections we would like to implement this next
> > week and move projects to https://invent.kde.org.
> >
> > Thanks!
> > Bhushan for sysadmin team
> >
> > [1] 
> > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
>
> Does this mean that to clone it we'll have to go "git clone
> kde:games/knetwalk" or something along the lines?

Yes.

>
> If that's the case I'd much prefer if we didn't do this, at the moment
> it's already uncomfortable for me to remember the URL for some of the
> repos (e.g. is it sysadmin/ or not?), this will only increase the
> problem and I personally don't see the advantage.

So you'd rather that we have no way to easily see a list of just
Plasma / Frameworks / PIM / etc reviews?
(See https://invent.kde.org/groups/kde/-/merge_requests for an example
of the problem)

Not to mention the fact that there will be several hundred
repositories all in one group, so they will be completely
undiscoverable to anyone outside of our community.

>
> e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
> krita graphics or its own thing?
>
> I really prefer when I don't have to guess this kind of things when
> fetching a repository.

There is always the search on Gitlab, and you can keep a checkout of
sysadmin/repo-metadata for grepping on.

>
> Aleix

Cheers,
Ben


Re: Information regarding upcoming Gitlab Migration

2020-04-27 Thread Ben Cooksley
On Mon, Apr 27, 2020 at 7:26 PM Ilya Bizyaev  wrote:
>
> Hello Bhushan!
>
> Thank you for you work on the Gitlab migration!
>
> The lists look good! Here are some ideas that I have, in case you think they 
> can be considered before we transition:
> • The "applications" category is somewhat misleading to me: it does not 
> include all KDE applications, and not all repositories in that category are 
> applications either. Looking through the list of projects in there, I think 
> they can be safely distributed across other categories. Most complicated 
> there are IMO kate, dolphin, klook, konqueror, konsole and yakuake. Somehow 
> terminal emulators, file managers and text editors feel like they belong to 
> the same category, but I don't know how to call it; maybe "files"?

We are aware that the name is not ideal yes, and alternative names
would definitely be welcome for this group of projects.

Alternatively, they could be transferred into other categories (as it
looks like most of them would fit within 'utilities' even if they are
rather essential ones)

> • Tentative, but I think a category called "science" might make sense 
> creating. Since KDE regularly attempts to promote usage of our software in 
> scientific institutions, that wouldn't hurt either. E.g. Mark (an app for 
> data science) doesn't really belong in "education", and I think is also true 
> for labplot and rkward.
> • I see a category named "others". Looking at its contents, maybe it can be 
> renamed to "community"?

Most of these will in the long run be archived, so this category may
not end up being included in the final structure.

>
> Looking forward to the move!
>
> Cheers,
> Ilya.

Thanks,
Ben

>
>
>  Дата: Пн, 27 апр 2020 04:40:01 +0300 Bhushan Shah  
> написал(а) 
>
> [Please keep sysad...@kde.org list or bs...@kde.org in the CC for
> replies]
>
> Hello Community members,
>
> In view of upcoming Gitlab migration, we sysadmin team wants to share
> the recommended structuring for the repositories on Gitlab.
>
> We had multiple options,
>
> - Flat structure: In this option we would have everything under one
> single namespace/group: https://invent.kde.org/kde/knetwalk
> - Subgroups under top-level group: In this option we would have a groups
> under KDE namespace: https://invent.kde.org/kde/games/knetwalk
> - Groups at top level: In this option we would establish a series of
> groups at the top level, e.g. https://invent.kde.org/games/knetwalk
>
> We have discussed this with small but representative group of
> contributors or maintainers, and based on their suggestions, we
> recommend that we go with option 3. Having sub-groups at top level will
> allow us to,
>
> - Provides good visibility on all reviews, tasks and other items within
> the groups/modules we define
> - Provides improvements to discoverability of projects
> - Makes it possible for groups of projects to establish a group level
> task board should it fit their needs (for tracking a release for
> instance)
> - Makes the most semantic sense, as the ‘KDE’ top level group suggested
> in option 2 is duplicative considering the Gitlab instance is under
> kde.org.
> - The discoverability of projects is maximised, as there is no need to
> open the top level ‘KDE’ group before going into the subgroup.
>
> I've worked on draft "move" of the current set of the repositories in
> their respective subgroups at the repo-metadata project's branch [1].
> You can browse the directory structure to get idea of how final
> structure on Gitlab would look like.
>
> If we don't have any objections we would like to implement this next
> week and move projects to https://invent.kde.org.
>
> Thanks!
> Bhushan for sysadmin team
>
> [1] 
> https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
>
> --
> Bhushan Shah
> http://blog.bshah.in
> IRC Nick : bshah on Freenode
> GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D
>
>
>


Re: Information regarding upcoming Gitlab Migration

2020-04-27 Thread Ben Cooksley
On Mon, Apr 27, 2020 at 6:33 PM Rolf Eike Beer  
wrote:
>
> Bhushan Shah wrote:
>
> > I've worked on draft "move" of the current set of the repositories in
> > their respective subgroups at the repo-metadata project's branch [1].
> > You can browse the directory structure to get idea of how final
> > structure on Gitlab would look like.
>
> No objection, just a request for clarification: it looks like everything
> in extragear or playground was merged into there, right?

That is correct - the Extragear/Playground/"KDE" modules aren't
represented in this.

>
> Eike

Cheers,
Ben


Re: Fwd: KDE CI: Administration » Dependency Build Plasma stable-kf5-qt5 FreeBSDQt5.14 - Build # 8 - Still Failing!

2020-04-20 Thread Ben Cooksley
On Mon, Apr 20, 2020 at 10:29 AM Friedrich W. H. Kossebau
 wrote:
>
> Am Sonntag, 19. April 2020, 21:13:01 CEST schrieb Ben Cooksley:
> > Hi all,
> >
> > Another breakage in Qt?
>
> Should be fixed now (restarted build now completed), with similar traps also
> removed for the future, thanks to David Faure for the work done and Ade for
> the root detecting investigations.

Thanks all for taking a look into this and making the necessary fixes!

>
> Seems Qt changed for Qt 5.14.1 -> 5.14.2 some wrappers around QSet-related API
> from
> #if QT_VERSION < QT_VERSION_CHECK(6,0,0)
> to
> #if QT_DEPRECATED_SINCE(5, 14) && QT_VERSION < QT_VERSION_CHECK(6,0,0)
> and by that stronger rules some projects no longer saw code they saw before,
> thus had started to fail.
>
> Cheers
> Friedrich
>
>

Cheers,
Ben


D6794: assert the testpackage appstream data validates

2020-04-20 Thread Ben Cooksley
bcooksley added a comment.


  I've added it in 
https://invent.kde.org/sysadmin/ci-tooling/commit/cd1eb8d0a91502f8aaf0c7fc402060bd38a3cf25
 and have now initiated an image rebuild

REPOSITORY
  R290 KPackage

REVISION DETAIL
  https://phabricator.kde.org/D6794

To: sitter, sebas, apol
Cc: bcooksley, dfaure, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns


Fwd: KDE CI: Administration » Dependency Build Plasma stable-kf5-qt5 FreeBSDQt5.14 - Build # 8 - Still Failing!

2020-04-19 Thread Ben Cooksley
Hi all,

Another breakage in Qt?

Cheers,
Ben

-- Forwarded message -
From: CI System 
Date: Sun, Apr 19, 2020 at 11:44 PM
Subject: KDE CI: Administration » Dependency Build Plasma stable-kf5-qt5
FreeBSDQt5.14 - Build # 8 - Still Failing!
To: 


*BUILD FAILURE*
Build URL
https://build.kde.org/job/Administration/job/Dependency%20Build%20Plasma%20stable-kf5-qt5%20FreeBSDQt5.14/8/
Project: Dependency Build Plasma stable-kf5-qt5 FreeBSDQt5.14
Date of build: Sun, 19 Apr 2020 11:17:06 +
Build duration: 27 min and counting
* CONSOLE OUTPUT *
[...truncated 114019 lines...]
[2020-04-19T11:44:31.964Z] In file included from
/usr/home/jenkins/workspace/Administration/Dependency Build Plasma
stable-kf5-qt5
FreeBSDQt5.14/kactivitymanagerd/src/service/plugins/sqlite/ResourceLinking.h:26:
[2020-04-19T11:44:31.964Z] In file included from
/usr/local/include/boost/container/flat_set.hpp:27:
[2020-04-19T11:44:31.964Z] In file included from
/usr/local/include/boost/container/new_allocator.hpp:24:
[2020-04-19T11:44:31.964Z]
/usr/local/include/boost/container/throw_exception.hpp:88:25: warning:
address of array 'msg' will always evaluate to 'true'
[-Wpointer-bool-conversion]
[2020-04-19T11:44:31.964Z] BOOST_ASSERT_MSG(!msg, str);
[2020-04-19T11:44:31.964Z] ~^~~
[2020-04-19T11:44:31.964Z] /usr/local/include/boost/assert.hpp:61:46: note:
expanded from macro 'BOOST_ASSERT_MSG'
[2020-04-19T11:44:31.964Z] # define BOOST_ASSERT_MSG(expr, msg)
assert((expr)&&(msg))
[2020-04-19T11:44:31.964Z] ^~~~
[2020-04-19T11:44:31.964Z] /usr/include/assert.h:56:21: note: expanded from
macro 'assert'
[2020-04-19T11:44:31.964Z] #define assert(e) ((e) ? (void)0 :
__assert(__func__, __FILE__, \
[2020-04-19T11:44:31.964Z] ^
[2020-04-19T11:44:31.964Z] 6 warnings generated.
[2020-04-19T11:44:31.964Z] In file included from
/usr/home/jenkins/workspace/Administration/Dependency Build Plasma
stable-kf5-qt5
FreeBSDQt5.14/kactivitymanagerd/build/src/service/plugins/sqlite/resourcescoringadaptor.cpp:11:
[2020-04-19T11:44:31.964Z] In file included from
/usr/home/jenkins/workspace/Administration/Dependency Build Plasma
stable-kf5-qt5
FreeBSDQt5.14/kactivitymanagerd/build/src/service/plugins/sqlite/resourcescoringadaptor.h:17:
[2020-04-19T11:44:31.964Z] In file included from
/usr/home/jenkins/workspace/Administration/Dependency Build Plasma
stable-kf5-qt5
FreeBSDQt5.14/kactivitymanagerd/src/service/plugins/sqlite/StatsPlugin.h:27:
[2020-04-19T11:44:31.964Z] In file included from
/usr/local/include/boost/container/flat_set.hpp:27:
[2020-04-19T11:44:31.964Z] In file included from
/usr/local/include/boost/container/new_allocator.hpp:24:
[2020-04-19T11:44:31.964Z]
/usr/local/include/boost/container/throw_exception.hpp:56:21: warning:
address of array 'msg' will always evaluate to 'true'
[-Wpointer-bool-conversion]
[2020-04-19T11:44:31.964Z] BOOST_ASSERT(!msg);
[2020-04-19T11:44:31.964Z] ~^~~
[2020-04-19T11:44:31.964Z] /usr/local/include/boost/assert.hpp:60:36: note:
expanded from macro 'BOOST_ASSERT'
[2020-04-19T11:44:31.964Z] # define BOOST_ASSERT(expr) assert(expr)
[2020-04-19T11:44:31.964Z] ^~~~
[2020-04-19T11:44:31.964Z] /usr/include/assert.h:56:21: note: expanded from
macro 'assert'
[2020-04-19T11:44:31.964Z] #define assert(e) ((e) ? (void)0 :
__assert(__func__, __FILE__, \
[2020-04-19T11:44:31.964Z] ^
[2020-04-19T11:44:31.964Z] In file included from
/usr/home/jenkins/workspace/Administration/Dependency Build Plasma
stable-kf5-qt5
FreeBSDQt5.14/kactivitymanagerd/build/src/service/plugins/sqlite/resourcescoringadaptor.cpp:11:
[2020-04-19T11:44:31.964Z] In file included from
/usr/home/jenkins/workspace/Administration/Dependency Build Plasma
stable-kf5-qt5
FreeBSDQt5.14/kactivitymanagerd/build/src/service/plugins/sqlite/resourcescoringadaptor.h:17:
[2020-04-19T11:44:31.964Z] In file included from
/usr/home/jenkins/workspace/Administration/Dependency Build Plasma
stable-kf5-qt5
FreeBSDQt5.14/kactivitymanagerd/src/service/plugins/sqlite/StatsPlugin.h:27:
[2020-04-19T11:44:31.964Z] In file included from
/usr/local/include/boost/container/flat_set.hpp:27:
[2020-04-19T11:44:31.964Z] In file included from
/usr/local/include/boost/container/new_allocator.hpp:24:
[2020-04-19T11:44:31.964Z]
/usr/local/include/boost/container/throw_exception.hpp:64:25: warning:
address of array 'msg' will always evaluate to 'true'
[-Wpointer-bool-conversion]
[2020-04-19T11:44:31.964Z] BOOST_ASSERT_MSG(!msg, str);
[2020-04-19T11:44:31.964Z] ~^~~
[2020-04-19T11:44:31.964Z] /usr/local/include/boost/assert.hpp:61:46: note:
expanded from macro 'BOOST_ASSERT_MSG'
[2020-04-19T11:44:31.964Z] # define BOOST_ASSERT_MSG(expr, msg)
assert((expr)&&(msg))
[2020-04-19T11:44:31.964Z] ^~~~
[2020-04-19T11:44:31.964Z] /usr/include/assert.h:56:21: note: expanded from
macro 'assert'
[2020-04-19T11:44:31.964Z] #define assert(e) ((e) ? (void)0 :
__assert(__func__, __FILE__, \
[2020-04-19T11:44:31.964Z] ^
[2020-04-19T11:44:31.965Z] In file included from

Re: Fwd: KDE CI: Administration » Dependency Build Plasma stable-kf5-qt5 FreeBSDQt5.14 - Build # 7 - Still Failing!

2020-04-18 Thread Ben Cooksley
On Sun, Apr 19, 2020 at 3:13 AM David Faure  wrote:
>
> On Saturday, April 18, 2020 5:06:43 PM CEST Friedrich W. H. Kossebau wrote:
> > Am Samstag, 18. April 2020, 16:26:57 CEST schrieb David Faure:
> > > On Saturday, April 18, 2020 7:09:25 AM CEST Ben Cooksley wrote:
> > > > Hi all,
> > > >
> > > > Please see below - any ideas as to why KHelpCenter no longer
> > > > successfully
> > > > builds?
> > > >
> > > > It doesn't look like KHelpCenter has changed...
> > >
> > > No, Qt has.
> >
> > My question though is why. This would be a ABI-breaking change, no?
> > And khelpcenter nowhere disables deprecated Qt API, from what I can tell.
> >
> > Does something smuggle in e.g. via CMake config file compile flags a
> > QT_DISABLE_DEPRECATED_BEFORE=0x050e00 perhaps? Or is something flawed with
> > the Qt packages on FreeBSD side?
>
> Good question, this is supposed to be just a warning.
> No idea :(

Thanks for looking into this everyone!

Cheers,
Ben

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


D6794: assert the testpackage appstream data validates

2020-04-18 Thread Ben Cooksley
bcooksley added a comment.


  I wonder if it is a coincidence that the images used to run the CI system we 
rebuilt in the past 48 hours - could this be an update to appstreamcli that is 
causing this perhaps?

REPOSITORY
  R290 KPackage

REVISION DETAIL
  https://phabricator.kde.org/D6794

To: sitter, sebas, apol
Cc: bcooksley, dfaure, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns


Fwd: KDE CI: Administration » Dependency Build Plasma stable-kf5-qt5 FreeBSDQt5.14 - Build # 7 - Still Failing!

2020-04-17 Thread Ben Cooksley
Hi all,

Please see below - any ideas as to why KHelpCenter no longer successfully
builds?

It doesn't look like KHelpCenter has changed...

Cheers,
Ben

-- Forwarded message -
From: CI System 
Date: Sat, Apr 18, 2020 at 4:38 PM
Subject: KDE CI: Administration » Dependency Build Plasma stable-kf5-qt5
FreeBSDQt5.14 - Build # 7 - Still Failing!
To: 


*BUILD FAILURE*
Build URL
https://build.kde.org/job/Administration/job/Dependency%20Build%20Plasma%20stable-kf5-qt5%20FreeBSDQt5.14/7/
Project: Dependency Build Plasma stable-kf5-qt5 FreeBSDQt5.14
Date of build: Sat, 18 Apr 2020 04:09:43 +
Build duration: 28 min and counting
* CONSOLE OUTPUT *
[...truncated 117391 lines...]
[2020-04-18T04:38:09.745Z] Scanning dependencies of target testmetainfo
[2020-04-18T04:38:09.745Z] [ 22%] Built target
doc-onlinehelp-index-cache-bz2
[2020-04-18T04:38:09.745Z] [ 23%] Building CXX object
searchhandlers/CMakeFiles/khc_xapianindexer.dir/htmltextdump.cpp.o
[2020-04-18T04:38:10.007Z] [ 25%] Building CXX object
tests/CMakeFiles/testmetainfo.dir/testmetainfo_autogen/mocs_compilation.cpp.o
[2020-04-18T04:38:10.007Z] [ 27%] Building CXX object
searchhandlers/CMakeFiles/khc_xapianindexer.dir/cachereader.cpp.o
[2020-04-18T04:38:10.007Z] [ 28%] Building CXX object
searchhandlers/CMakeFiles/khc_xapianindexer.dir/xapiancommon.cpp.o
[2020-04-18T04:38:10.007Z] [ 30%] Building CXX object
searchhandlers/CMakeFiles/khc_xapianindexer.dir/xapianindexer.cpp.o
[2020-04-18T04:38:10.007Z] [ 32%] Building CXX object
tests/CMakeFiles/testmetainfo.dir/testmetainfo.cpp.o
[2020-04-18T04:38:10.007Z] [ 33%] Building CXX object
tests/CMakeFiles/testmetainfo.dir/__/docmetainfo.cpp.o
[2020-04-18T04:38:10.007Z] [ 33%] Built target
doc-khelpcenter-index-cache-bz2
[2020-04-18T04:38:10.007Z] [ 35%] Building CXX object
tests/CMakeFiles/testmetainfo.dir/__/docentry.cpp.o
[2020-04-18T04:38:10.265Z] [ 35%] Built target doc-glossary-index-cache-bz2
[2020-04-18T04:38:10.265Z] [ 37%] Building CXX object
tests/CMakeFiles/testmetainfo.dir/__/docentrytraverser.cpp.o
[2020-04-18T04:38:10.524Z] [ 37%] Built target
doc-fundamentals-index-cache-bz2
[2020-04-18T04:38:10.524Z] [ 38%] Building CXX object
tests/CMakeFiles/testmetainfo.dir/khc_debug.cpp.o
[2020-04-18T04:38:10.524Z] [ 38%] Built target kdeinit_khelpcenter_autogen
[2020-04-18T04:38:10.524Z] [ 40%] Building CXX object
tests/CMakeFiles/testmetainfo.dir/prefs.cpp.o
[2020-04-18T04:38:11.094Z]
/usr/home/jenkins/workspace/Administration/Dependency Build Plasma
stable-kf5-qt5
FreeBSDQt5.14/khelpcenter/searchhandlers/cachereader.cpp:108:10: error: no
member named 'fromList' in 'QSet'; did you mean
'QStack::fromList'?
[2020-04-18T04:38:11.094Z] return QSet::fromList(
mRanges.uniqueKeys() );
[2020-04-18T04:38:11.094Z] ^~~
[2020-04-18T04:38:11.094Z] QStack::fromList
[2020-04-18T04:38:11.094Z] /usr/local/include/qt5/QtCore/qvector.h:301:23:
note: 'QStack::fromList' declared here
[2020-04-18T04:38:11.094Z] static QVector fromList(const QList );
[2020-04-18T04:38:11.094Z] ^
[2020-04-18T04:38:11.094Z] [ 42%] Generating prefs.h, prefs.cpp
[2020-04-18T04:38:11.094Z] 1 error generated.
[2020-04-18T04:38:11.094Z] gmake[2]: ***
[searchhandlers/CMakeFiles/khc_xapianindexer.dir/build.make:96:
searchhandlers/CMakeFiles/khc_xapianindexer.dir/cachereader.cpp.o] Error 1
[2020-04-18T04:38:11.094Z] gmake[2]: *** Waiting for unfinished jobs
[2020-04-18T04:38:11.354Z] [ 44%] Linking CXX executable
../bin/khc_xapiansearch
[2020-04-18T04:38:11.354Z] [ 44%] Built target khc_xapiansearch
[2020-04-18T04:38:11.354Z] Scanning dependencies of target
kdeinit_khelpcenter
[2020-04-18T04:38:11.354Z] [ 47%] Building CXX object
CMakeFiles/kdeinit_khelpcenter.dir/navigatorappgroupitem.cpp.o
[2020-04-18T04:38:11.354Z] [ 47%] Building CXX object
CMakeFiles/kdeinit_khelpcenter.dir/kdeinit_khelpcenter_autogen/mocs_compilation.cpp.o
[2020-04-18T04:38:11.354Z] [ 49%] Building CXX object
CMakeFiles/kdeinit_khelpcenter.dir/searchwidget.cpp.o
[2020-04-18T04:38:11.354Z] [ 50%] Building CXX object
CMakeFiles/kdeinit_khelpcenter.dir/docmetainfo.cpp.o
[2020-04-18T04:38:11.354Z] [ 54%] Building CXX object
CMakeFiles/kdeinit_khelpcenter.dir/navigator.cpp.o
[2020-04-18T04:38:11.354Z] [ 54%] Building CXX object
CMakeFiles/kdeinit_khelpcenter.dir/navigatoritem.cpp.o
[2020-04-18T04:38:11.354Z] [ 57%] Building CXX object
CMakeFiles/kdeinit_khelpcenter.dir/view.cpp.o
[2020-04-18T04:38:11.354Z] [ 57%] Building CXX object
CMakeFiles/kdeinit_khelpcenter.dir/navigatorappitem.cpp.o
[2020-04-18T04:38:11.354Z] [ 59%] Building CXX object
CMakeFiles/kdeinit_khelpcenter.dir/searchengine.cpp.o
[2020-04-18T04:38:11.354Z] [ 61%] Building CXX object
CMakeFiles/kdeinit_khelpcenter.dir/docentrytraverser.cpp.o
[2020-04-18T04:38:11.613Z] gmake[1]: *** [CMakeFiles/Makefile2:570:
searchhandlers/CMakeFiles/khc_xapianindexer.dir/all] Error 2
[2020-04-18T04:38:11.614Z] gmake[1]: *** Waiting for unfinished jobs
[2020-04-18T04:38:11.614Z] [ 62%] Building 

Re: KDE CI: Administration » Dependency Build Extragear stable-kf5-qt5 AndroidQt5.14 - Build # 10 - Still Failing!

2020-04-17 Thread Ben Cooksley
On Fri, Apr 17, 2020 at 8:28 AM Nicolas Fella  wrote:
>
> Hi,

Hi Nicolas,

>
>
>
> this looks like a simple prison build failure to me. However, I cannot 
> reprocuce this with the binary factory container and the current Prison 
> Android CI builds is blue. There is a single red Android build in the Prison 
> CI history 
> (https://build.kde.org/job/Frameworks/job/prison/job/kf5-qt5%20AndroidQt5.14/5/)
>  with what appears to be the same error message. Not sure how to explain that 
> though.
>

Thanks for taking a look.

I've now done a rebuild of the image and after that the Dependency
Build ran through fine - so all sorted now!

>
>
> Nico

Cheers,
Ben

>
>
>
>
>
> On Donnerstag, 16. April 2020 21:10:44 CEST Ben Cooksley wrote:
>
> > On Fri, Apr 17, 2020 at 6:37 AM Johan Ouwerkerk  
> > wrote:
>
> > > On Thu, Apr 16, 2020 at 10:51 AM Ben Cooksley  wrote:
>
> > >> Hi all,
>
> > >>
>
> > >> Does anyone know why the below would have suddenly started failing a
>
> > >> little while back?
>
> > >>
>
> > >> Thanks,
>
> > >> Ben
>
> > >
>
> > > Based on the error message I would expect this to be related to the effort
>
> > > to fix Android pkgs not being generated for both 32bit and 64bit ARM.
>
> > I see. Do we have a timeline for this being fixed?
>
> >
>
> > > Regards,
>
> > >
>
> > > - Johan
>
> >
>
> > Cheers,
>
> > Ben
>
>
>
>


Re: KDE CI: Administration » Dependency Build Extragear stable-kf5-qt5 AndroidQt5.14 - Build # 10 - Still Failing!

2020-04-16 Thread Ben Cooksley
On Fri, Apr 17, 2020 at 6:37 AM Johan Ouwerkerk  wrote:
>
>
> On Thu, Apr 16, 2020 at 10:51 AM Ben Cooksley  wrote:
>>
>> Hi all,
>>
>> Does anyone know why the below would have suddenly started failing a little 
>> while back?
>>
>> Thanks,
>> Ben
>
>
> Based on the error message I would expect this to be related to the effort to 
> fix Android pkgs not being generated for both 32bit and 64bit ARM.

I see. Do we have a timeline for this being fixed?

>
> Regards,
>
> - Johan

Cheers,
Ben


D28755: Breeze Icons cannot be built from read-only source location

2020-04-16 Thread Ben Cooksley
bcooksley added a comment.


  This does not build on the CI system - please see 
https://build.kde.org/view/Failing/job/Administration/job/Dependency%20Build%20Applications%20kf5-qt5%20SUSEQt5.12/lastFailedBuild/
 amongst others.

REPOSITORY
  R266 Breeze Icons

REVISION DETAIL
  https://phabricator.kde.org/D28755

To: marten, #breeze, ngraham
Cc: bcooksley, ngraham, pino, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, bruns


Fwd: KDE CI: Administration » Dependency Build Extragear stable-kf5-qt5 AndroidQt5.14 - Build # 10 - Still Failing!

2020-04-16 Thread Ben Cooksley
Hi all,

Does anyone know why the below would have suddenly started failing a little
while back?

Thanks,
Ben


-- Forwarded message -
From: CI System 
Date: Thu, Apr 16, 2020 at 6:59 AM
Subject: KDE CI: Administration » Dependency Build Extragear stable-kf5-qt5
AndroidQt5.14 - Build # 10 - Still Failing!
To: 


*BUILD FAILURE*
Build URL
https://build.kde.org/job/Administration/job/Dependency%20Build%20Extragear%20stable-kf5-qt5%20AndroidQt5.14/10/
Project: Dependency Build Extragear stable-kf5-qt5 AndroidQt5.14
Date of build: Wed, 15 Apr 2020 18:56:12 +
Build duration: 3 min 20 sec and counting
* CONSOLE OUTPUT *
[...truncated 14565 lines...]
[2020-04-15T18:59:30.261Z] -- You can export a target by specifying
-DQTANDROID_EXPORTED_TARGET= and -DANDROID_APK_DIR=
[2020-04-15T18:59:30.261Z] -- You can export a target by specifying
-DQTANDROID_EXPORTED_TARGET= and -DANDROID_APK_DIR=
[2020-04-15T18:59:30.261Z] -- Check for working C compiler:
/opt/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/clang
[2020-04-15T18:59:30.261Z] -- Check for working C compiler:
/opt/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -- works
[2020-04-15T18:59:30.261Z] -- Detecting C compiler ABI info
[2020-04-15T18:59:30.261Z] -- Detecting C compiler ABI info - done
[2020-04-15T18:59:30.261Z] -- Detecting C compile features
[2020-04-15T18:59:30.261Z] -- Detecting C compile features - done
[2020-04-15T18:59:30.261Z] -- Check for working CXX compiler:
/opt/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++
[2020-04-15T18:59:30.261Z] -- Check for working CXX compiler:
/opt/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++ -- works
[2020-04-15T18:59:30.261Z] -- Detecting CXX compiler ABI info
[2020-04-15T18:59:30.518Z] -- Detecting CXX compiler ABI info - done
[2020-04-15T18:59:30.518Z] -- Detecting CXX compile features
[2020-04-15T18:59:30.518Z] -- Detecting CXX compile features - done
[2020-04-15T18:59:30.518Z] --
[2020-04-15T18:59:30.518Z]
[2020-04-15T18:59:30.518Z] Installing in /home/user/install-prefix. Run
/home/user/workspace/Administration/Dependency Build Extragear
stable-kf5-qt5 AndroidQt5.14/prison/build/prefix.sh to set the environment
for prison.
[2020-04-15T18:59:30.518Z] -- Could not set up the appstream test.
appstreamcli is missing.
[2020-04-15T18:59:30.518Z] -- Looking for __GLIBC__
[2020-04-15T18:59:30.518Z] -- Looking for __GLIBC__ - not found
[2020-04-15T18:59:30.518Z] -- Performing Test _OFFT_IS_64BIT
[2020-04-15T18:59:30.518Z] -- Performing Test _OFFT_IS_64BIT - Failed
[2020-04-15T18:59:30.518Z] -- Performing Test HAVE_DATE_TIME
[2020-04-15T18:59:30.518Z] -- Performing Test HAVE_DATE_TIME - Success
[2020-04-15T18:59:30.518Z] -- Found QRencode:
/home/user/install-prefix/lib/libqrencode.a
[2020-04-15T18:59:30.518Z] -- Could NOT find Dmtx (missing: Dmtx_LIBRARIES
Dmtx_INCLUDE_DIRS)
[2020-04-15T18:59:30.518Z] -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
[2020-04-15T18:59:30.777Z] -- Performing Test
COMPILER_HAS_HIDDEN_VISIBILITY - Success
[2020-04-15T18:59:30.777Z] -- Performing Test
COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
[2020-04-15T18:59:30.777Z] -- Performing Test
COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success
[2020-04-15T18:59:30.777Z] -- Performing Test COMPILER_HAS_DEPRECATED_ATTR
[2020-04-15T18:59:30.777Z] -- Performing Test COMPILER_HAS_DEPRECATED_ATTR
- Success
[2020-04-15T18:59:30.777Z] -- The following OPTIONAL packages have been
found:
[2020-04-15T18:59:30.777Z]
[2020-04-15T18:59:30.777Z] * Qt5Network (required version >= 5.14.1)
[2020-04-15T18:59:30.777Z] * Qt5Qml (required version >= 5.14.1)
[2020-04-15T18:59:30.777Z] * Qt5QmlModels (required version >= 5.14.1)
[2020-04-15T18:59:30.777Z] * Qt5Quick
[2020-04-15T18:59:30.777Z]
[2020-04-15T18:59:30.777Z] -- The following REQUIRED packages have been
found:
[2020-04-15T18:59:30.777Z]
[2020-04-15T18:59:30.777Z] * ECM (required version >= 5.69.0), Extra CMake
Modules., 
[2020-04-15T18:59:30.777Z] * Qt5Core
[2020-04-15T18:59:30.777Z] * Qt5Gui
[2020-04-15T18:59:30.777Z] * QRencode, The QRencode library, <
https://fukuchi.org/works/qrencode/>
[2020-04-15T18:59:30.777Z] * Qt5Test
[2020-04-15T18:59:30.777Z] * Qt5Widgets
[2020-04-15T18:59:30.777Z] * Qt5 (required version >= 5.12.0)
[2020-04-15T18:59:30.777Z]
[2020-04-15T18:59:30.777Z] -- The following features have been disabled:
[2020-04-15T18:59:30.777Z]
[2020-04-15T18:59:30.777Z] * QCH, API documentation in QCH format (for e.g.
Qt Assistant, Qt Creator & KDevelop)
[2020-04-15T18:59:30.777Z]
[2020-04-15T18:59:30.777Z] -- The following RECOMMENDED packages have not
been found:
[2020-04-15T18:59:30.777Z]
[2020-04-15T18:59:30.777Z] * Dmtx, The Datamatrix library, <
https://github.com/dmtx/libdmtx>
[2020-04-15T18:59:30.777Z]
[2020-04-15T18:59:30.777Z] -- Configuring done
[2020-04-15T18:59:30.777Z] -- Generating done
[2020-04-15T18:59:30.777Z] CMake Warning:
[2020-04-15T18:59:30.777Z] Manually-specified 

Re: Update on Status of Gitlab Migration

2020-04-14 Thread Ben Cooksley
On Tue, Apr 14, 2020 at 2:37 PM Nate Graham  wrote:
>
> On 4/13/20 6:59 PM, Ben Cooksley wrote:
> > Why do we need to mimic them?
> >
> > If you Google "KDE Gitlab" then the first hit is invent.kde.org
> > <http://invent.kde.org>.
>
> To flip it around: why do we need to do something different? I don't
> think it's about mimicking anyone else, but rather using the most
> intuitively obvious domain name rather than some arbitrarily different one.
>
> No matter what, we're all going to be talking about "KDE GitLab" or
> "KDE's GitLab instance". The title of the relevant documentation page is
> "GitLab" (much as the Phabricator documentation page was named
> "Phabricator"). And when the migration is complete, we're all going to
> announce that "KDE is now using GitLab!" So the cat's out of the bag on
> using the word "GitLab" and avoiding some number of people looking for
> our stuff at gitlab.com and not finding it there. invent.kde.org doesn't
> avoid that at all.
>
> Given that, which is more confusing: explaining to people that we have a
> GitLab instance at invent.kde.org, or explaining to people that we have
> a GitLab instance at gitlab.kde.org?

There is no difference to be honest, the amount of explaining is
exactly the same.

We're also not alone in giving ours a different name - Debian did as
well (theirs is at salsa.debian.org). They didn't see fit to setup a
compatibility "gitlab.debian.org" hostname either.

>
> I know that over the next few years I'm going to be directing hundreds
> of people towards our infrastructure, and I would rather be able to say
> "please submit a pull request at gitlab.kde.org" rather than "please
> submit a pull request at KDE's GitLab instance at invent.kde.org."

Sorry, but the "KDE's Gitlab instance" in your second sentence is superfluous.
You could just as easily say "please submit a pull request on
invent.kde.org", not sure why you need to explicitly mention it is
Gitlab.

If people have already found the source code, chances are they will
have already found invent.kde.org anyway - as they will have probably
found it via a web browser, and Gitlab will be the only web interface
to our repositories (CGit is being discontinued)

>
> I know this probably feels like annoyingly extreme bikeshedding, but, I
> dunno, names are important.
>
> Nate

Cheers,
Ben


Re: Update on Status of Gitlab Migration

2020-04-14 Thread Ben Cooksley
On Mon, Apr 13, 2020 at 9:29 AM Johan Ouwerkerk  wrote:
>
> On Sun, Apr 12, 2020 at 12:49 AM Johan Ouwerkerk  
> wrote:
> >
> > >
> > > We may need to do on-the-fly conversion of the kde: repo paths if they
> > > won't be expressible as 'kde:foo' in the future, but we should have the
> > > information needed to do this in kdesrc-build to make this happen
> > > on-the-fly.
> > >
> >
> > Yes, this should be fairly straight forward: we could do a `git remote
> > set-url` based on what the repo metadata tells us before updating a
> > local clone. In fact: we could build this right now and sell it as
> > "automagically recover your upstream".  :)
> >
> > I might try to hack something up tomorrow or monday for that.
> >
>
> A basic version of this is now available via:
> https://invent.kde.org/kde/kdesrc-build/-/merge_requests/27
> With this feature sysadmin should now be free to change the repopath
> value in the metadata YAML and kdesrc-build will reconfigure the
> remote URL appropriately automatically. This works as long as the same
> `kde:$path` expression works for both fetch and push, i.e. the layout
> on the anongit.kde.org network must match with the layout of
> git.kde.org/invent.kde.org. If necessary a simple path prefix change
> could still work with a minor update to the pushInsteadOf mapping,
> e.g. when repos on invent are mapped to kde/   instead of
> /.
>
> You can also experiment with setting invent.kde.org as the push URL by
> setting x-invent-kde-push-urls to true in your rc file. The effect
> should be visible through git remote -vv afterwards. (Disable the
> setting and re-run again afterwards because this will obviously break
> your push URLs as long as the Gitlab migration hasn't completed yet).

Many thanks for sending this patch through Johan, it's appreciated.

As one of the options we are looking at involves grouping
repositories, having the ability for kdesrc-build to seamlessly handle
this transition is definitely appreciated.


>
> Regards,
>
> - Johan

Cheers,
Ben


Re: Update on Status of Gitlab Migration

2020-04-13 Thread Ben Cooksley
On Tue, 14 Apr 2020, 11:45 am Aleix Pol,  wrote:

> On Mon, Apr 13, 2020 at 8:30 PM Ben Cooksley  wrote:
> >
> > On Tue, Apr 14, 2020 at 3:35 AM Nate Graham  wrote:
> > >
> > > On 4/13/20 4:44 AM, Albert Vaca Cintora wrote:
> > > > Regarding this: is the subdomain going to stay invent.kde.org once
> we
> > > > have officially moved? I find it's a bit confusing to use that
> instead
> > > > of gitlab.kde.org
> > >
> > > I agree. gitlab.kde.org would make more sense to me, mirroring
> > > phabricator.kde.org.
> > >
> >
> > There is no intention to change the name from invent.kde.org.
> >
> > We have a long precedent of not using the name of the software for the
> > name in DNS, and Gitlab is continuing with this, for example:
> > - bugs.kde.org is run by Bugzilla
> > - dot.kde.org is run by Drupal
> > - techbase.kde.org is run by Mediawiki
> > - conf.kde.org is run by Frab
> > - reimbursements.kde.org is run by travel-support-program
> > - websvn.kde.org is run by ViewVC
> > - build.kde.org and binary-factory.kde.org are both run by Jenkins
> > - stats.kde.org is run by Matomo (formerly Piwik)
> > - survey.kde.org is run by Limesurvey
> >
> > For essentially all of the above, calling it after the software
> > running it makes no sense, and given that in some cases we have
> > multiple instances would have made things more confusing
> > (jenkins1.kde.org and jenkins2.kde.org anyone?)
> >
> > Phabricator and Reviewboard were the only ones to not follow this
> > rule, and that was an error on our part.
> >
> > Given that there is a popular instance at Gitlab.com, referring to
> > ours as "KDE Invent" is more likely to ensure newcomers are not
> > confused (as they may not be aware that you can setup an instance of
> > Gitlab on your own systems)
> >
> > Regards,
> > Ben
>
> We also use git.kde.org and svn.kde.org.
>

The name git.kde.org will be retired as part of the move to Gitlab.

The SSH host keys for the two machines are different, so it would cause
more issues than it doesn't to keep the hostname active.

We've also never supported HTTP access to the master copy of the
repositories so there isn't anything to keep alive there either.


> It would too mimic what others are doing at gitlab.gnome.org and
> gitlab.freedesktop.org. So at the very least we'll want a redirect.
>

Why do we need to mimic them?

If you Google "KDE Gitlab" then the first hit is invent.kde.org.


> Aleix
>

Cheers,
Ben

>


Re: Update on Status of Gitlab Migration

2020-04-13 Thread Ben Cooksley
On Tue, Apr 14, 2020 at 3:35 AM Nate Graham  wrote:
>
> On 4/13/20 4:44 AM, Albert Vaca Cintora wrote:
> > Regarding this: is the subdomain going to stay invent.kde.org once we
> > have officially moved? I find it's a bit confusing to use that instead
> > of gitlab.kde.org
>
> I agree. gitlab.kde.org would make more sense to me, mirroring
> phabricator.kde.org.
>

There is no intention to change the name from invent.kde.org.

We have a long precedent of not using the name of the software for the
name in DNS, and Gitlab is continuing with this, for example:
- bugs.kde.org is run by Bugzilla
- dot.kde.org is run by Drupal
- techbase.kde.org is run by Mediawiki
- conf.kde.org is run by Frab
- reimbursements.kde.org is run by travel-support-program
- websvn.kde.org is run by ViewVC
- build.kde.org and binary-factory.kde.org are both run by Jenkins
- stats.kde.org is run by Matomo (formerly Piwik)
- survey.kde.org is run by Limesurvey

For essentially all of the above, calling it after the software
running it makes no sense, and given that in some cases we have
multiple instances would have made things more confusing
(jenkins1.kde.org and jenkins2.kde.org anyone?)

Phabricator and Reviewboard were the only ones to not follow this
rule, and that was an error on our part.

Given that there is a popular instance at Gitlab.com, referring to
ours as "KDE Invent" is more likely to ensure newcomers are not
confused (as they may not be aware that you can setup an instance of
Gitlab on your own systems)

Regards,
Ben


Re: Update on Status of Gitlab Migration

2020-04-11 Thread Ben Cooksley
On Sun, Apr 12, 2020 at 11:04 AM Johan Ouwerkerk  wrote:
>
> On Sun, Apr 12, 2020 at 12:49 AM Johan Ouwerkerk  
> wrote:
> >
> > Yes the only reason why a cleanup script might be needed is if the
> > logical path used to express the repo in dependency information
> > changes at the same time. E.g. suppose a `frameworks/kf5foo` gets
> > remapped to `frameworks/kf5/foo` or something like that. In that case
> > unless you use the flat repository layout, kdesrc-build would try to
> > clone a new `frameworks/kf5/foo` repo, leaving your old
> > `frameworks/kf5foo` to consume some wasted disk space.
> >
>
> This is obviously a poor example, but the same problem occurs if
> something moves from playground to extragear. Basically if the
> `projectpath` YAML key changes.

I had been considering adding the Gitlab Project ID number to the YAML
metadata files as a way of allowing us to track projects through their
whole lifetime.

>
> Regards,
>
> - Johan

Cheers,
Ben


Re: Update on Status of Gitlab Migration

2020-04-11 Thread Ben Cooksley
On Sat, Apr 11, 2020 at 11:31 PM Johan Ouwerkerk  wrote:
>
> On Sat, Apr 11, 2020 at 11:36 AM Ben Cooksley  wrote:
> >
> > Should anyone have any questions on the above, please let us know.
> >
>
> Does the migration also mean that `git.kde.org` push URL will be
> retired and would need to be remapped to `invent.kde.org`?

Yes, the hostname git.kde.org will be fully retired as part of this transition.

>From my understanding kdesrc-build will automatically pick this up
once we update sysadmin/repo-metadata to show the new repository
paths.
This is something we'll confirm with mpyne though to ensure we can
make the cutover as smooth as possible.

Depending on how things look we may also make available a script that
will update the configuration of a repository to reflect both the
change in hostname as well as the change in path.

>
> In that case, it would be good to have a grace period after the
> initial migration to Gitlab so kdesrc-build (etc.) could be updated
> before the cut off date to perform this migration automatically for
> the user. I expect such a grace period would not need to last very
> long because the feature would be trivial to implement.
>
> Regards,
>
> - Johan

Cheers,
Ben


Notice of upcoming changes to the behaviour of the anongit network

2020-04-11 Thread Ben Cooksley
Hi all,

As part of the preparations for the move to Gitlab, and the rewrite of
our anongit tooling, one of the things we have looked into is how the
anongit network in general operates.

As part of this, it has been observed that the git:// protocol is
unencrypted, and thus vulnerable to intercept and manipulation by
hostile actors.

We have therefore decided that support for the git:// protocol to
access KDE Git repositories will cease following our migration to
Gitlab.

Going forward, all anonymous access should take place instead over
https, which is encrypted, and has the added benefit of offering
support for redirects (should those be needed)

Should anyone have any questions regarding this, please let us know.

Thanks,
Ben Cooksley
KDE Sysadmin


Update on Status of Gitlab Migration

2020-04-11 Thread Ben Cooksley
Good morning Community,

I'm pleased to report that this week we reached a major milestone,
with all the necessary technical components now being in place on our
side for our migration to Gitlab to take place.

This includes the replacement of the tooling that supports the anongit
network, as well as implementation of a system to sync changes from
Identity to Gitlab in real time.

As part of this, the anongit network following the migration to Gitlab
should pick up new repositories, along with changes to default
branches, project descriptions, repository names and their path, and
the deletion of repositories within 10 seconds of the change taking
place on Gitlab (effectively making it real time)

We are currently looking to confirm how repositories will be organised
on Gitlab, after which we should be able to confirm how and when we
perform the migration.

Please note that only code hosting and code review will be
transitioning at this time - CI and tasks will follow later on.
Existing reviews on Phabricator will not be imported to Gitlab as part
of this process and will need to be closed out on Phabricator.

To help assist with this, it would be appreciated if all holders of a
KDE Developer account could please login on our Gitlab instance (at
https://invent.kde.org/) and ensure they are listed as a 'Developer'
of the KDE group. You can do this by checking the 'Groups' tab of your
Profile on Gitlab.

Should you not be listed as a Developer of the group, and you have
previously logged into Gitlab, please visit KDE Identity and make a
change to your details there, which will trigger a sync of your
account to Gitlab.

Should anyone have any questions on the above, please let us know.

Thanks,
Ben Cooksley
KDE Sysadmin


D28400: [AdvancedQueryParser] Move semantic handling of tokens to SearchStore

2020-04-07 Thread Ben Cooksley
bcooksley added a comment.


  Sorry, but that isn't how this works. Also, you will notice that one of the 
failing platforms is FreeBSD. Which is freely available and OSS.
  
  The responsibility of people to keep code compiling rests with those working 
on it. Should there be platform specific issues they may from time to time get 
assistance from those who look after those platforms, but in general the 
responsibility lies with the person working on the code.
  
  The FreeBSD failure is most likely due to Clang being more strict with C++ 
than GCC is.
  
  As for Windows, that looks to be a namespacing issue.

REPOSITORY
  R293 Baloo

REVISION DETAIL
  https://phabricator.kde.org/D28400

To: bruns, #baloo, ngraham
Cc: bcooksley, kossebau, kde-frameworks-devel, hurikhan77, lots0logs, 
LeGast00n, cblack, fbampaloukas, GB_2, domson, ashaposhnikov, michaelh, 
astippich, spoorun, ngraham, bruns, abrahams


D28400: [AdvancedQueryParser] Move semantic handling of tokens to SearchStore

2020-04-07 Thread Ben Cooksley
bcooksley added a comment.


  The following is notice that the following reviews/commits are being 
scheduled to be reverted in 24 hours due to the FTBFS on Windows and FreeBSD:
  
  - 2b9c468816459a318dd2c8fe96e5e5acf1cedfd1 

  - 2fa16a2865dc385f1106c3eadb363bbe9d1244b1 

  - d4494ee496640325fb6fd72b80f12c5c4b124d22 


REPOSITORY
  R293 Baloo

REVISION DETAIL
  https://phabricator.kde.org/D28400

To: bruns, #baloo, ngraham
Cc: bcooksley, kossebau, kde-frameworks-devel, hurikhan77, lots0logs, 
LeGast00n, cblack, fbampaloukas, GB_2, domson, ashaposhnikov, michaelh, 
astippich, spoorun, ngraham, bruns, abrahams


D25660: Decouple KBookmarksMenu from KActionCollection

2020-03-27 Thread Ben Cooksley
bcooksley added a comment.


  Thanks. That macro really does cause quite a bit of trouble...

REPOSITORY
  R294 KBookmarks

REVISION DETAIL
  https://phabricator.kde.org/D25660

To: nicolasfella, #frameworks, dfaure
Cc: bcooksley, kossebau, dfaure, apol, kde-frameworks-devel, LeGast00n, cblack, 
GB_2, michaelh, ngraham, bruns


D25660: Decouple KBookmarksMenu from KActionCollection

2020-03-27 Thread Ben Cooksley
bcooksley added a comment.


  Could this commit be the cause of 
https://build.kde.org/job/Applications/job/krdc/job/stable-kf5-qt5%20FreeBSDQt5.14/3/consoleText
  (ie. this commit is SIC?)

REPOSITORY
  R294 KBookmarks

REVISION DETAIL
  https://phabricator.kde.org/D25660

To: nicolasfella, #frameworks, dfaure
Cc: bcooksley, kossebau, dfaure, apol, kde-frameworks-devel, LeGast00n, cblack, 
GB_2, michaelh, ngraham, bruns


D14707: autotests: skip '/' fstab check with zfs

2020-03-21 Thread Ben Cooksley
bcooksley added a comment.


  That is strange - as our FreeBSD Builders definitely have an /etc/fstab file:
  
root@FreeBSDBuilderIota:~ # cat /etc/fstab 
# DeviceMountpoint  FStype  Options Dump
Pass#
/dev/vtbd0p2noneswapsw  0   0
  
  I've checked and the file is definitely world-readable - and is the same on 
all three builders.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D14707

To: dfaure, adridg
Cc: bcooksley, bruns, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, 
ngraham


D27986: Allow providing an error message from the application

2020-03-17 Thread Ben Cooksley
bcooksley added a comment.


  The following is notice that I intend to revert this change, along with the 
corresponding commits that make use of this functionality in Dr Konqi, as they 
cause a FTBFS on both FreeBSD and Windows which has not been addressed.
  This regression is over a week old at this point.
  
  Please see 
https://build.kde.org/view/Failing/job/Plasma/job/drkonqi/job/kf5-qt5%20FreeBSDQt5.13/lastFailedBuild/
 and 
https://build.kde.org/view/Failing/job/Plasma/job/drkonqi/job/kf5-qt5%20WindowsMSVCQt5.14/lastFailedBuild/
 for more information.

REPOSITORY
  R285 KCrash

REVISION DETAIL
  https://phabricator.kde.org/D27986

To: apol, #frameworks, sitter, dfaure
Cc: bcooksley, dfaure, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, 
ngraham, bruns


D27855: [Debug] Improve readability of positioninfo debug format

2020-03-17 Thread Ben Cooksley
bcooksley added a comment.


  One of the changes in this string of 4 revisions has unfortunately broken the 
build of Baloo on the CI system.
  Please see 
https://build.kde.org/view/Failing/job/Frameworks/job/baloo/job/kf5-qt5%20FreeBSDQt5.13/90/console

REPOSITORY
  R293 Baloo

REVISION DETAIL
  https://phabricator.kde.org/D27855

To: bruns, #baloo, ngraham
Cc: bcooksley, kde-frameworks-devel, hurikhan77, lots0logs, LeGast00n, cblack, 
fbampaloukas, GB_2, domson, ashaposhnikov, michaelh, astippich, spoorun, 
ngraham, bruns, abrahams


Fwd: KDE CI: Plasma » drkonqi » kf5-qt5 WindowsMSVCQt5.14 - Build # 13 - Still Failing!

2020-03-16 Thread Ben Cooksley
Hi Aleix and Harald,

The below appears to have been caused by recent changes you've made to Dr
Konqi and KCrash - mind taking a look?

Note that FreeBSD is also affected by this breakage.

Cheers,
Ben

-- Forwarded message -
From: CI System 
Date: Tue, 17 Mar 2020, 6:42 AM
Subject: KDE CI: Plasma » drkonqi » kf5-qt5 WindowsMSVCQt5.14 - Build # 13
- Still Failing!
To: , , 


*BUILD FAILURE*
Build URL
https://build.kde.org/job/Plasma/job/drkonqi/job/kf5-qt5%20WindowsMSVCQt5.14/13/
Project: kf5-qt5 WindowsMSVCQt5.14
Date of build: Mon, 16 Mar 2020 17:41:10 +
Build duration: 1 min 11 sec and counting
* CONSOLE OUTPUT *
[...truncated 346 lines...]
[2020-03-16T17:42:12.886Z] * KF5JobWidgets (required version >= 5.61.0)
[2020-03-16T17:42:12.886Z] * KF5KIO (required version >= 5.61.0)
[2020-03-16T17:42:12.886Z] * KF5Crash (required version >= 5.61.0)
[2020-03-16T17:42:12.886Z] * KF5Completion (required version >= 5.61.0)
[2020-03-16T17:42:12.886Z] * KF5WidgetsAddons (required version >= 5.61.0)
[2020-03-16T17:42:12.886Z] * KF5Wallet (required version >= 5.61.0)
[2020-03-16T17:42:12.886Z] * KF5Notifications (required version >= 5.61.0)
[2020-03-16T17:42:12.886Z] * KF5IdleTime (required version >= 5.61.0)
[2020-03-16T17:42:12.886Z] * KF5WindowSystem (required version >= 5.61.0)
[2020-03-16T17:42:12.886Z] * KF5 (required version >= 5.61.0)
[2020-03-16T17:42:12.886Z] * KDEWin
[2020-03-16T17:42:12.886Z] * Qt5Test
[2020-03-16T17:42:12.886Z]
[2020-03-16T17:42:12.886Z] -- The following features have been disabled:
[2020-03-16T17:42:12.886Z]
[2020-03-16T17:42:12.886Z] * DrKonqiIntegrationTesting, Needs Ruby,
functional atspi gem, gdb, as well as xvfb-run.
[2020-03-16T17:42:12.886Z]
[2020-03-16T17:42:12.886Z] -- The following RECOMMENDED packages have not
been found:
[2020-03-16T17:42:12.886Z]
[2020-03-16T17:42:12.886Z] * Qt5X11Extras (required version >= 5.12.0)
[2020-03-16T17:42:12.886Z] Recommended for better integration on X11.
[2020-03-16T17:42:12.886Z]
[2020-03-16T17:42:12.886Z] -- Configuring done
[2020-03-16T17:42:13.832Z] -- Generating done
[2020-03-16T17:42:13.832Z] -- Build files have been written to: C:/CI/Job
Build/build
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Compiling)
[Pipeline] bat
[2020-03-16T17:42:14.953Z]
[2020-03-16T17:42:14.953Z] C:\CI\Job Build>call "C:/Program Files
(x86)/Microsoft Visual
Studio/2019/Professional/VC/Auxiliary/Build/vcvars64.bat"
[2020-03-16T17:42:14.953Z]
**
[2020-03-16T17:42:14.953Z] ** Visual Studio 2019 Developer Command Prompt
v16.4.3
[2020-03-16T17:42:14.953Z] ** Copyright (c) 2019 Microsoft Corporation
[2020-03-16T17:42:14.953Z]
**
[2020-03-16T17:42:15.890Z] [vcvarsall.bat] Environment initialized for:
'x64'
[2020-03-16T17:42:15.890Z] [1/149] Automatic MOC for target crashtest
[2020-03-16T17:42:16.150Z] [2/149] Building CXX object
src\tests\crashtest\CMakeFiles\crashtest.dir\crashtest_autogen\mocs_compilation.cpp.obj
[2020-03-16T17:42:16.150Z] [3/149] Automatic MOC for target
drkonqi_backtrace_parser
[2020-03-16T17:42:16.150Z] [4/149] Automatic MOC for target qbugzilla
[2020-03-16T17:42:16.150Z] [5/149] Automatic MOC for target kdbgwin
[2020-03-16T17:42:17.090Z] [6/149] Building CXX object
src\parser\CMakeFiles\drkonqi_backtrace_parser.dir\backtraceparserlldb.cpp.obj
[2020-03-16T17:42:17.090Z] [7/149] Building CXX object
src\parser\CMakeFiles\drkonqi_backtrace_parser.dir\drkonqi_backtrace_parser_autogen\mocs_compilation.cpp.obj
[2020-03-16T17:42:17.090Z] [8/149] Building CXX object
src\parser\CMakeFiles\drkonqi_backtrace_parser.dir\backtraceparsernull.cpp.obj
[2020-03-16T17:42:17.090Z] [9/149] Building CXX object
src\parser\CMakeFiles\drkonqi_backtrace_parser.dir\backtraceparsercdb.cpp.obj
[2020-03-16T17:42:17.090Z] [10/149] Building CXX object
src\parser\CMakeFiles\drkonqi_backtrace_parser.dir\backtraceparserkdbgwin.cpp.obj
[2020-03-16T17:42:17.090Z] [11/149] Building CXX object
src\bugzillaintegration\libbugzilla\CMakeFiles\qbugzilla.dir\bugzilla.cpp.obj
[2020-03-16T17:42:17.090Z] [12/149] Building CXX object
src\parser\CMakeFiles\drkonqi_backtrace_parser.dir\drkonqi_parser_debug.cpp.obj
[2020-03-16T17:42:17.090Z] [13/149] Building CXX object
src\bugzillaintegration\libbugzilla\CMakeFiles\qbugzilla.dir\connection.cpp.obj
[2020-03-16T17:42:17.350Z] [14/149] Building CXX object
src\parser\CMakeFiles\drkonqi_backtrace_parser.dir\backtraceparsergdb.cpp.obj
[2020-03-16T17:42:17.350Z] [15/149] Building CXX object
src\bugzillaintegration\libbugzilla\CMakeFiles\qbugzilla.dir\apijob.cpp.obj
[2020-03-16T17:42:17.350Z] [16/149] Building CXX object
src\parser\CMakeFiles\drkonqi_backtrace_parser.dir\backtraceparser.cpp.obj
[2020-03-16T17:42:17.611Z] [17/149] Building CXX object
src\tests\crashtest\CMakeFiles\crashtest.dir\crashtest.cpp.obj
[2020-03-16T17:42:17.875Z] [18/149] Building CXX object

Re: KDE CI: Applications » kreversi » kf5-qt5 FreeBSDQt5.13 - Build # 26 - Still Failing!

2020-03-16 Thread Ben Cooksley
On Mon, Mar 16, 2020 at 10:24 PM David Edmundson
 wrote:
>
> There is not a SIC. KIO is fine
>
> It's merely this crap again:
>
> if (EXISTS "${CMAKE_SOURCE_DIR}/.git")
>add_definitions(-DQT_DISABLE_DEPRECATED_BEFORE=0x06)
>add_definitions(-DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x06)
> endif()

May I suggest that we tweak this macro so that passing 0x06 makes
it no-op and fail open (disabling nothing)?
We have had way too many build failures due to this.

>
> in kreversi
>
> In plasma I ported all these to:
>add_definitions(-DKF_DISABLE_DEPRECATED_BEFORE_AND_AT= kf5 version we 
> depend on at time of release
>
> on kossebau's suggestion
>
> David

Cheers,
Ben


Fwd: KDE CI: Applications » kreversi » kf5-qt5 FreeBSDQt5.13 - Build # 26 - Still Failing!

2020-03-16 Thread Ben Cooksley
This appears to be yet more fallout due to the regression within KIO.

I'm therefore treating this as a Source Incompatibie Change to KIO, and
will be reverting that change in 24 hours unless someone has an alternative
solution.

Cheers,
Ben

-- Forwarded message -
From: CI System 
Date: Mon, Mar 16, 2020 at 9:51 PM
Subject: KDE CI: Applications » kreversi » kf5-qt5 FreeBSDQt5.13 - Build #
26 - Still Failing!
To: , 


*BUILD FAILURE*
Build URL
https://build.kde.org/job/Applications/job/kreversi/job/kf5-qt5%20FreeBSDQt5.13/26/
Project: kf5-qt5 FreeBSDQt5.13
Date of build: Mon, 16 Mar 2020 08:50:05 +
Build duration: 40 sec and counting
* CONSOLE OUTPUT *
[...truncated 277 lines...]
[2020-03-16T08:50:35.165Z] * Qt5Quick (required version >= 5.12.0)
[2020-03-16T08:50:35.165Z] * ECM (required version >= 1.6.0)
[2020-03-16T08:50:35.165Z] * KF5Declarative (required version >= 5.30.0)
[2020-03-16T08:50:35.165Z] * KF5IconThemes (required version >= 5.30.0)
[2020-03-16T08:50:35.165Z] * KF5KIO (required version >= 5.30.0)
[2020-03-16T08:50:35.165Z] * KF5XmlGui (required version >= 5.30.0)
[2020-03-16T08:50:35.165Z] * KF5 (required version >= 5.30.0)
[2020-03-16T08:50:35.165Z] * Qt5Network (required version >= 5.9.0)
[2020-03-16T08:50:35.165Z] * Qt5QuickWidgets (required version >= 5.9.0)
[2020-03-16T08:50:35.165Z] * Qt5Qml (required version >= 5.9.0)
[2020-03-16T08:50:35.165Z] * Gettext
[2020-03-16T08:50:35.165Z] * KF5I18n (required version >= 5.46.0)
[2020-03-16T08:50:35.165Z] * KF5CoreAddons (required version >= 5.68.0)
[2020-03-16T08:50:35.165Z] * KF5Auth (required version >= 5.68.0)
[2020-03-16T08:50:35.165Z] * KF5Codecs (required version >= 5.68.0)
[2020-03-16T08:50:35.165Z] * KF5WidgetsAddons (required version >= 5.68.0)
[2020-03-16T08:50:35.165Z] * KF5ConfigWidgets (required version >= 5.46.0)
[2020-03-16T08:50:35.165Z] * Qt5Widgets (required version >= 5.12.0)
[2020-03-16T08:50:35.165Z] * KF5Completion (required version >= 5.46.0)
[2020-03-16T08:50:35.165Z] * KF5KDEGames (required version >= 4.9.0)
[2020-03-16T08:50:35.165Z] * Qt5Core
[2020-03-16T08:50:35.165Z]
[2020-03-16T08:50:35.165Z] -- Configuring done
[2020-03-16T08:50:35.165Z] -- Generating done
[2020-03-16T08:50:35.444Z] -- Build files have been written to:
/usr/home/jenkins/workspace/Applications/kreversi/kf5-qt5
FreeBSDQt5.13/build
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Compiling)
[Pipeline] sh
[2020-03-16T08:50:36.359Z] + python3 -u ci-tooling/helpers/compile-build.py
--product Applications --project kreversi --branchGroup kf5-qt5 --platform
FreeBSDQt5.13 --usingInstall /home/jenkins/install-prefix/
[2020-03-16T08:50:36.621Z] Scanning dependencies of target kreversi_autogen
[2020-03-16T08:50:36.621Z] Scanning dependencies of target
doc-index-cache-bz2
[2020-03-16T08:50:36.621Z] [ 7%] Automatic MOC for target kreversi
[2020-03-16T08:50:36.621Z] [ 7%] Generating index.cache.bz2
[2020-03-16T08:50:38.123Z] [ 7%] Built target doc-index-cache-bz2
[2020-03-16T08:50:38.827Z] [ 7%] Built target kreversi_autogen
[2020-03-16T08:50:38.827Z] [ 11%] Generating qrc_kreversi.cpp
[2020-03-16T08:50:38.827Z] [ 15%] Generating ui_startgamedialog.h
[2020-03-16T08:50:38.827Z] [ 19%] Generating preferences.h, preferences.cpp
[2020-03-16T08:50:39.130Z] Scanning dependencies of target kreversi
[2020-03-16T08:50:39.131Z] [ 23%] Building CXX object
CMakeFiles/kreversi.dir/kreversi_autogen/mocs_compilation.cpp.o
[2020-03-16T08:50:39.131Z] [ 26%] Building CXX object
CMakeFiles/kreversi.dir/commondefs.cpp.o
[2020-03-16T08:50:39.131Z] [ 30%] Building CXX object
CMakeFiles/kreversi.dir/colorscheme.cpp.o
[2020-03-16T08:50:39.131Z] [ 34%] Building CXX object
CMakeFiles/kreversi.dir/kreversiview.cpp.o
[2020-03-16T08:50:39.131Z] [ 38%] Building CXX object
CMakeFiles/kreversi.dir/kreversigame.cpp.o
[2020-03-16T08:50:39.131Z] [ 42%] Building CXX object
CMakeFiles/kreversi.dir/kreversihumanplayer.cpp.o
[2020-03-16T08:50:39.131Z] [ 46%] Building CXX object
CMakeFiles/kreversi.dir/kreversicomputerplayer.cpp.o
[2020-03-16T08:50:39.411Z] [ 50%] Building CXX object
CMakeFiles/kreversi.dir/kreversiplayer.cpp.o
[2020-03-16T08:50:39.411Z] [ 53%] Building CXX object
CMakeFiles/kreversi.dir/Engine.cpp.o
[2020-03-16T08:50:39.411Z] [ 57%] Building CXX object
CMakeFiles/kreversi.dir/startgamedialog.cpp.o
[2020-03-16T08:50:39.411Z] [ 61%] Building CXX object
CMakeFiles/kreversi.dir/kexthighscore.cpp.o
[2020-03-16T08:50:39.411Z] [ 65%] Building CXX object
CMakeFiles/kreversi.dir/highscores.cpp.o
[2020-03-16T08:50:42.110Z] [ 69%] Building CXX object
CMakeFiles/kreversi.dir/kexthighscore_gui.cpp.o
[2020-03-16T08:50:42.110Z] [ 73%] Building CXX object
CMakeFiles/kreversi.dir/kexthighscore_internal.cpp.o
[2020-03-16T08:50:42.110Z] [ 76%] Building CXX object
CMakeFiles/kreversi.dir/kexthighscore_item.cpp.o
[2020-03-16T08:50:42.110Z] [ 80%] Building CXX object
CMakeFiles/kreversi.dir/kexthighscore_tab.cpp.o
[2020-03-16T08:50:42.110Z] [ 84%] Building CXX object

D27893: Use fallback also on Windows not only mac

2020-03-06 Thread Ben Cooksley
bcooksley accepted this revision.
bcooksley added a comment.
This revision is now accepted and ready to land.


  Looks good to me!

REPOSITORY
  R289 KNotifications

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D27893

To: vonreth, broulik, bcooksley, jjazeix, cullmann
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


Re: kreversi 19.12 fails to build at IconSize call

2020-03-01 Thread Ben Cooksley
On Mon, Mar 2, 2020 at 2:19 AM Christoph Feck  wrote:
>
> Hi,
>
> kreversi release/19.12 branch fails to build with this error on CI:
>
>
> pageItem->setIcon(QIcon::fromTheme(icon).pixmap(IconSize(KIconLoader::Toolbar)));
>  error: IconSize was not declared in this scope
>
> See
> https://build.kde.org/job/Applications/view/Everything%20-%20stable-kf5-qt5/job/kreversi/
>
> Additionally, kwordquiz fails to build on Windows CI,
> see
> https://build.kde.org/job/Applications/view/Everything%20-%20stable-kf5-qt5/job/kwordquiz/

The KWordQuiz error is due to a regression in Frameworks, the fix for
which is at https://phabricator.kde.org/D27355

>
> I would be glad if someone could investigate these issues.
>
> Thanks,
> Christoph

Cheers,
Ben

>
> --
> Christoph Feck
> KDE Release Team


D27355: POC: Make kstatusnotifieritem available without dbus

2020-03-01 Thread Ben Cooksley
bcooksley added a comment.


  Have you had a chance to look into this @broulik?

REPOSITORY
  R289 KNotifications

REVISION DETAIL
  https://phabricator.kde.org/D27355

To: vonreth, bcooksley, jjazeix, broulik
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


D27557: Auto-generate 24px monochrome icons

2020-02-24 Thread Ben Cooksley
bcooksley added a comment.


  Please note that the FreeBSD breakage has now started to cause Dependency 
Builds on the CI system to fail.

REPOSITORY
  R266 Breeze Icons

REVISION DETAIL
  https://phabricator.kde.org/D27557

To: ngraham, #vdg, ndavis, #frameworks, sitter
Cc: bcooksley, kossebau, kde-frameworks-devel, LeGast00n, cblack, GB_2, 
michaelh, ngraham, bruns


Re: Banning QNetworkAccessManager

2020-02-21 Thread Ben Cooksley
On Thu, Feb 20, 2020 at 9:57 PM Volker Krause  wrote:
>
> On Wednesday, 19 February 2020 10:04:11 CET Ben Cooksley wrote:
> > On Wed, Feb 19, 2020 at 9:30 PM Volker Krause  wrote:
> > > On Wednesday, 19 February 2020 08:05:01 CET Ben Cooksley wrote:
> > > > On Mon, Feb 3, 2020 at 7:42 AM Volker Krause  wrote:
> > > > > I agree on the problem of QNAM's default, see also
> > > > > https://conf.kde.org/en/
> > > > > akademy2019/public/events/135 on that subject.
> > > > >
> > > > > On Saturday, 1 February 2020 23:24:14 CET Ben Cooksley wrote:
> > > > > [...]
> > > > >
> > > > > > Prior to now, i've taken the approach of advertising that
> > > > > > QNetworkAccessManager is broken and needs a flag set within
> > > > > > applications when used, however unfortunately this seems to have
> > > > > > been
> > > > > > an ineffective approach and cases of broken behaviour continue to
> > > > > > appear (despite this brokeness being known about and advertised
> > > > > > since
> > > > > > back in the Qt 4.x series when this class was introduced)
> > > > > >
> > > > > > Therefore, given the Qt Project is unlikely to change their position
> > > > >
> > > > > > on this, I would like to propose the following:
> > > > > The Qt Project is actually in favor of changing at least the
> > > > > redirection
> > > > > default to exactly what we want it to be.
> > > > > https://codereview.qt-project.org/c/qt/qtbase/+/273175 has the change,
> > > > > and
> > > > > got approval both by Lars and one of the maintainers. It is merely
> > > > > stuck
> > > > > in dealing with the unit test fallout in Qt's CI that somebody has to
> > > > > take care of. Doesn't immediately help us of course, but claiming Qt
> > > > > is
> > > > > unwilling to change this is simply wrong.
> > > > >
> > > > > > 1) That effective immediately, QNetworkAccessManager and it's
> > > > > > children
> > > > > > classes be banned and prohibited within KDE software, to be enforced
> > > > > > by server side hooks.
> > > > > > 2) That we fork QNetworkAccessManager and the associated classes
> > > > > > within the appropriate Framework (to be determined), where the
> > > > > > defective behaviour can then be corrected.
> > > > >
> > > > > While this might solve the redirection problem, it brings us yet
> > > > > another
> > > > > then unmaintained HTTP implementation next to the one in KIO, which is
> > > > > a
> > > > > far bigger problem long term. We need less of those, not more.
> > > > >
> > > > > To address the problem of people not using the correct defaults, I did
> > > > > propose a much less extreme approach in the above mentioned talk at
> > > > > Akademy, namely having a KNetworkAccessManager as a sub-class of QNAM
> > > > > in
> > > > > a low-tier frameworks that essentially just enables redirects and
> > > > > HSTS.
> > > > > QNAM's implementation isn't the problem after all, the defaults are.
> > > > >
> > > > > Commit hooks warning about QNAM usage might still be a good idea, but
> > > > > as a
> > > > > warning only. Hard blocking QNAM-using code would block at least three
> > > > > repos I spend a lot of time on currently, none of which even talks to
> > > > > KDE
> > > > > servers.
> > > > >
> > > > > If you need to take more drastic measures against code not doing this
> > > > > correctly regardless, you can do that my dropping the server-side
> > > > > workarounds. Yes, that would break the affected application possibly,
> > > > > but
> > > > > at least it would not cause massive collateral damage for the people
> > > > > using this correctly.
> > > > >
> > > > > It would also help to know where specifically we have that problem, so
> > > > > we
> > > > > can actually solve it, and so we can figure out why we failed to fix
> > > > > this
> > > > > there earlier.
> > > >
> > > >

Re: Fixing QNetworkAccessManager use

2020-02-20 Thread Ben Cooksley
On Thu, Feb 20, 2020 at 2:09 AM Friedrich W. H. Kossebau
 wrote:
>
> Am Mittwoch, 19. Februar 2020, 08:05:01 CET schrieb Ben Cooksley:
> > On Mon, Feb 3, 2020 at 7:42 AM Volker Krause  wrote:
> > > It would also help to know where specifically we have that problem, so we
> > > can actually solve it, and so we can figure out why we failed to fix this
> > > there earlier.
> >
> > Just bringing this up again - it seems we've not had much movement on
> > this aside from the Wiki page.
>
> The wiki page currently still just recommends to set
> "networkAccessManger->setAttribute(QNetworkRequest::FollowRedirectsAttribute,
> true);"
>
> Which seems simple, but possible not what is enough in all cases.
>
> So my open questions here to be able to act on code I contribute to are:
>
> a) What about the mentioned QNetworkRequest::NoLessSafeRedirectPolicy, in
> which cases should that be used and when not?

For interacting with download.kde.org / files.kde.org, I would advise
against using this policy, as they will in virtually all instances
redirect to mirrors (who don't support https and are http only)

>
> b) What about the HSTS stuff, when is that recommended?

That should be enabled yes.

>
> c) What is a sane number for QNetworkRequest::maximumRedirectsAllowed?

5 to 10 redirects is a relatively sane number I would expect. At the
most I would expect our servers to issue a maximum of 3 redirects in a
given chain of URLs.
If it is longer than that then we are doing something wrong.

>
> Both in general and when it comes to KDE servers.
>
> Personally I am still unsure what the actual issue is. Why are redirects
> needed at all. Why all the address changes all the time? The "U" in
> "URL"/"URI" is for "uniform", not "unstable", isn't it ;)

Please see my other email regarding this.

>
> Can you give some examples for URLs of resources our code uses on KDE servers,
> and why they needed to change?

Get Hot New Stuff functionality (Gen 1), originally using a static
file tree under http://download.kde.org/khotnewstuff/
This needed to change for two reasons:
1) Mandatory HTTPS
2) The benefit of having these files mirrored, considering their
extremely small size and declining client base (KDE 3 and parts of KDE
4) was negligible and creating more load on our systems to support the
mirroring process than we got in terms of benefit of having them
mirrored. We therefore transitioned to serving these through a CDN.

Get Hot New Stuff functionality (Gen 2), originally using a dynamic
web service at http://newstuff.kde.org/ and http://data.kstuff.org/
needed to change for two reasons:
1) Mandatory HTTPS
2) The dynamic web service had not been updated in several years, and
was dependent on a very specific system setup we hadn't been able to
replicate and needed to decomission due to it's age. We therefore
needed to convert it to static files, and arrange for those to be
hosted elsewhere in our systems. newstuff.kde.org now converts the
requests sent to it to redirects to specific static files to keep
applications using it working (which includes KF5 era applications who
still actively use this and in at least one case continue to be
released using this)

Get Hot New Stuff functionality (Gen 3), originally used a file at
http://download.kde.org/ocs/providers.xml (now at
https://autoconfig.kde.org/ocs/providers.xml)
This needed to change for two reasons:
1) Mandatory HTTPS
2) It was necessary for non-sysadmins (particularly those involved in
running store.kde.org) to be able to update the file directly. As the
server hosting download.kde.org is sensitive and doesn't support
deploying changes from Git when they are committed, we had to move the
file to a different subdomain which could support this.

Marble maps, originally hosted under http://download.kde.org/ and
later at http://files.kde.org/marble/maps/ and now at
https://maps.kde.org/,
This need to be moved for couple of reasons:
1) When we transitioned download.kde.org to be a mirror redirector, it
was no longer possible for us to easily host non-mirrored resources
under the same domain (and the maps weren't mirrored), requiring they
be moved to files.kde.org (which as an added benefit also made it
possible for developers to update the maps themselves)
2) Later, it was discovered that Marble performance for loading maps
using files.kde.org after it transitioned to being a mirror redirector
as well was quite poor due to the large number of http requests
involved. We therefore shifted it to a CDN based resource which
eliminated these performance issues, known as maps.kde.org.

KStars resources, originally hosted under
http://download.kde.org/apps/kstars/ needed to be moved to
https://files.kde.org/ for the following reasons:
1) Mandatory HTTPS
2) To allow developers to freely update

Re: Fixing QNetworkAccessManager use

2020-02-19 Thread Ben Cooksley
On Thu, Feb 20, 2020 at 9:58 AM Friedrich W. H. Kossebau
 wrote:
>
> Am Mittwoch, 19. Februar 2020, 21:01:20 CET schrieb Johan Ouwerkerk:
> > On Wed, Feb 19, 2020 at 2:09 PM Friedrich W. H. Kossebau
> >
> >  wrote:
> > > Personally I am still unsure what the actual issue is. Why are redirects
> > > needed at all. Why all the address changes all the time?
> >
> > It is part of the HTTP spec for servers to be able to inform clients
> > that resource /foo/bar has moved to /bar/baz, either temporarily or
> > permanently.
>
> :) Thanks for that explanation, but that was not my question here (that part I
> am well aware of, done my share of web stuff).
>
> It was rather: why are subdomain names and/or access paths not once properly
> designed, but instead changed so often that redirection seems so important to
> be a default feature? Just because one can?

Things don't change extremely often.
Sometimes however requirements or other factors change, which
necessitates changing where a resource is hosted.

When this happens, it is extremely useful to have the ability to
relocate it elsewhere.

To use an example, when we first setup files.kde.org it was used by a
couple of things, including Necessitas for the Qt binaries that get
downloaded on to end user (Android) devices. When this was first
established, traffic was well within the reasonable bounds we had
expected when setting this up, and everything was served directly by
our (single) server. This went quite well for a while.

Sometime a bit later, an application was released on Google Play that
used Necessitas which was *extremely* popular, to the extent it caused
around a terabyte of data to be used within 48 hours or so. Hetzner
bandwidth was at this time not only limited to 100mbps, but also
capped - with the limit being 5 TB per month and overage after that
resulting in a charge per terabyte.

We therefore made the decision to convert files.kde.org to a mirror
network (like was already in place for download.kde.org), with
redirection taking place using Mirrorbrain. We were able to complete
this transition quickly thanks to the generous support of some of our
mirrors who established mirrors of files.kde.org. Fortunately
Necessitas had full support for handling redirects, so this is
something we were able to accomplish without any issues.

Had redirect support not been available, we would have been left with
no way out at that time.

I also have other examples involving Marble (including where we got
bitten by QNetworkAccessManager for the very first time - back in
January 2012) and numerous other KDE Edu applications (all of which
fortunately avoided QNAM).

> When we write code, we try to keep API stable as much as possible, and only
> change API when really useful, and that means for the consumer. When doing
> references in text we try to have eternally stable pointers (thanks ISBN &
> Co.),
>
> But this request for stable URLs on the internet might be an idealistic fight
> against windmills of a web 1.0 person...
>
> Cheers
> Friedrich
>
>

Cheers,
Ben


Re: Banning QNetworkAccessManager

2020-02-19 Thread Ben Cooksley
On Wed, Feb 19, 2020 at 9:30 PM Volker Krause  wrote:
>
> On Wednesday, 19 February 2020 08:05:01 CET Ben Cooksley wrote:
> > On Mon, Feb 3, 2020 at 7:42 AM Volker Krause  wrote:
> > > I agree on the problem of QNAM's default, see also
> > > https://conf.kde.org/en/
> > > akademy2019/public/events/135 on that subject.
> > >
> > > On Saturday, 1 February 2020 23:24:14 CET Ben Cooksley wrote:
> > > [...]
> > >
> > > > Prior to now, i've taken the approach of advertising that
> > > > QNetworkAccessManager is broken and needs a flag set within
> > > > applications when used, however unfortunately this seems to have been
> > > > an ineffective approach and cases of broken behaviour continue to
> > > > appear (despite this brokeness being known about and advertised since
> > > > back in the Qt 4.x series when this class was introduced)
> > > >
> > > > Therefore, given the Qt Project is unlikely to change their position
> > >
> > > > on this, I would like to propose the following:
> > > The Qt Project is actually in favor of changing at least the redirection
> > > default to exactly what we want it to be.
> > > https://codereview.qt-project.org/c/qt/qtbase/+/273175 has the change, and
> > > got approval both by Lars and one of the maintainers. It is merely stuck
> > > in dealing with the unit test fallout in Qt's CI that somebody has to
> > > take care of. Doesn't immediately help us of course, but claiming Qt is
> > > unwilling to change this is simply wrong.
> > >
> > > > 1) That effective immediately, QNetworkAccessManager and it's children
> > > > classes be banned and prohibited within KDE software, to be enforced
> > > > by server side hooks.
> > > > 2) That we fork QNetworkAccessManager and the associated classes
> > > > within the appropriate Framework (to be determined), where the
> > > > defective behaviour can then be corrected.
> > >
> > > While this might solve the redirection problem, it brings us yet another
> > > then unmaintained HTTP implementation next to the one in KIO, which is a
> > > far bigger problem long term. We need less of those, not more.
> > >
> > > To address the problem of people not using the correct defaults, I did
> > > propose a much less extreme approach in the above mentioned talk at
> > > Akademy, namely having a KNetworkAccessManager as a sub-class of QNAM in
> > > a low-tier frameworks that essentially just enables redirects and HSTS.
> > > QNAM's implementation isn't the problem after all, the defaults are.
> > >
> > > Commit hooks warning about QNAM usage might still be a good idea, but as a
> > > warning only. Hard blocking QNAM-using code would block at least three
> > > repos I spend a lot of time on currently, none of which even talks to KDE
> > > servers.
> > >
> > > If you need to take more drastic measures against code not doing this
> > > correctly regardless, you can do that my dropping the server-side
> > > workarounds. Yes, that would break the affected application possibly, but
> > > at least it would not cause massive collateral damage for the people
> > > using this correctly.
> > >
> > > It would also help to know where specifically we have that problem, so we
> > > can actually solve it, and so we can figure out why we failed to fix this
> > > there earlier.
> >
> > Just bringing this up again - it seems we've not had much movement on
> > this aside from the Wiki page.
> >
> > Examining that Qt merge request, it not only is targeted at just Qt
> > 6.x, it also hasn't had any movement since the start of October 2019 -
> > 4 months ago.
> > Given that we are going to be on Qt 5.x for some time, that merge
> > request can't be considered to be the 'fix' for this issue.
>
> The targeting of Qt6 is due to this aiming at dev when that was still Qt 5.x,
> but you are right of course, somebody needs to do the work there to drive this
> to completion, no matter in which version it will actually land.

Indeed.

>
> > We need a solution that will ensure software released today doesn't
> > cause us pain in several years time, because as I illustrated in an
> > earlier email to this thread, software has a habit of remaining in use
> > for an extremely long amount of time (August 2014 being the release
> > date of the Marble versions in question hitting that old URL).
> >
> > The easiest path forward

Re: Banning QNetworkAccessManager

2020-02-18 Thread Ben Cooksley
On Mon, Feb 3, 2020 at 7:42 AM Volker Krause  wrote:
>
> I agree on the problem of QNAM's default, see also https://conf.kde.org/en/
> akademy2019/public/events/135 on that subject.
>
> On Saturday, 1 February 2020 23:24:14 CET Ben Cooksley wrote:
> [...]
> > Prior to now, i've taken the approach of advertising that
> > QNetworkAccessManager is broken and needs a flag set within
> > applications when used, however unfortunately this seems to have been
> > an ineffective approach and cases of broken behaviour continue to
> > appear (despite this brokeness being known about and advertised since
> > back in the Qt 4.x series when this class was introduced)
> >
> > Therefore, given the Qt Project is unlikely to change their position
> > on this, I would like to propose the following:
>
> The Qt Project is actually in favor of changing at least the redirection
> default to exactly what we want it to be.
> https://codereview.qt-project.org/c/qt/qtbase/+/273175 has the change, and got
> approval both by Lars and one of the maintainers. It is merely stuck in
> dealing with the unit test fallout in Qt's CI that somebody has to take care
> of. Doesn't immediately help us of course, but claiming Qt is unwilling to
> change this is simply wrong.
>
> > 1) That effective immediately, QNetworkAccessManager and it's children
> > classes be banned and prohibited within KDE software, to be enforced
> > by server side hooks.
> > 2) That we fork QNetworkAccessManager and the associated classes
> > within the appropriate Framework (to be determined), where the
> > defective behaviour can then be corrected.
>
> While this might solve the redirection problem, it brings us yet another then
> unmaintained HTTP implementation next to the one in KIO, which is a far bigger
> problem long term. We need less of those, not more.
>
> To address the problem of people not using the correct defaults, I did propose
> a much less extreme approach in the above mentioned talk at Akademy, namely
> having a KNetworkAccessManager as a sub-class of QNAM in a low-tier frameworks
> that essentially just enables redirects and HSTS. QNAM's implementation isn't
> the problem after all, the defaults are.
>
> Commit hooks warning about QNAM usage might still be a good idea, but as a
> warning only. Hard blocking QNAM-using code would block at least three repos I
> spend a lot of time on currently, none of which even talks to KDE servers.
>
> If you need to take more drastic measures against code not doing this
> correctly regardless, you can do that my dropping the server-side workarounds.
> Yes, that would break the affected application possibly, but at least it would
> not cause massive collateral damage for the people using this correctly.
>
> It would also help to know where specifically we have that problem, so we can
> actually solve it, and so we can figure out why we failed to fix this there
> earlier.

Just bringing this up again - it seems we've not had much movement on
this aside from the Wiki page.

Examining that Qt merge request, it not only is targeted at just Qt
6.x, it also hasn't had any movement since the start of October 2019 -
4 months ago.
Given that we are going to be on Qt 5.x for some time, that merge
request can't be considered to be the 'fix' for this issue.

We need a solution that will ensure software released today doesn't
cause us pain in several years time, because as I illustrated in an
earlier email to this thread, software has a habit of remaining in use
for an extremely long amount of time (August 2014 being the release
date of the Marble versions in question hitting that old URL).

The easiest path forward is to simply ban QNetworkAccessManager.

>
> Regards,
> Volker

Regards,
Ben


Re: 2 kirigami fixes for a point release

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

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

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

Re: 2 kirigami fixes for a point release

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

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

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

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

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

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

>
> Cheers,
>   Albert

Cheers,
Ben

>
> >
> >
>
>
>
>


Re: 2 kirigami fixes for a point release

2020-02-16 Thread Ben Cooksley
On Mon, Feb 17, 2020 at 4:42 AM David Edmundson
 wrote:
>
> > My point above was that the version you decide to freeze on should
> > only be the version you depend on during development.
> > The version you depend on when you release will be the next release of
> > Frameworks (so by freezing on 5.66 for development, it should have had
> > a release-day dependency of 5.67)
> >
> > The release of Plasma should then take place shortly after the
> > Frameworks version you have a release-day dependency on.
> >
>
> Just to clarify the current policy is:
>  - frameworks release 5.XX
>  - plasma beta
>  - frameworks release 5.XX+1
>  - plasma final
>
> Where 5.XX is the required version for Plasma. We set it as a dep,
> just after it gets released.
> We've had issues in the past, especially before frameworks had that
> 2nd Saturday of the month policy, but I don't think the current rules
> have a problem if followed.
>
> Within the context of this thread, we're dealing with issues that came
> up breaking at 5.XX+1, so after the freeze. Not technically new API,
> but behavioural changes.

Which raises the question of why those behavioural changes were going
in so close to the end.
If behavioural changes were needed by Plasma they should have been in
much earlier - ideally in the 5.XX release.

Do we know why they ended up landing at the very last minute?

>
> David

Cheers,
Ben


Re: 2 kirigami fixes for a point release

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

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

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

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

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

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

Cheers,
Ben


Re: 2 kirigami fixes for a point release

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

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

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

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

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

>
> Nate

Regards,
Ben


Re: 2 kirigami fixes for a point release

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

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

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

Cheers,
Ben


Re: 2 kirigami fixes for a point release

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

Can we please have a list of the offending distributions?

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

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

- Kirigami
- QQC2 Desktop Style

This is only a small number of Frameworks.

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

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

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

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

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

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

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

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

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

Regards,
Ben


D27355: POC: Make kstatusnotifieritem available without dbus

2020-02-12 Thread Ben Cooksley
bcooksley added inline comments.

INLINE COMMENTS

> kstatusnotifieritem.cpp:48
> +
> +#include 
>  #include 

New header?

> kstatusnotifieritem.cpp:617
>  void KStatusNotifierItem::showMessage(const QString , const QString 
> , const QString , int timeout)
>  {
>  #ifdef Q_OS_MACOS

Won't this mean that showMessage() is a no-op on Windows systems without D-Bus?
I would have thought that systemTrayIcon->showMessage() should be used here as 
well?

> kstatusnotifieritem.cpp:888
>  {
> +bool useLegacy = false;
> +#ifdef QT_DBUS_LIB

From my reading of the setLegacySystemTrayEnabled() won't setting it to false 
explicitly disable any form of system tray icon?

REPOSITORY
  R289 KNotifications

REVISION DETAIL
  https://phabricator.kde.org/D27355

To: vonreth, bcooksley, jjazeix
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


Re: KPeople/ECM/KConfig build regression

2020-02-07 Thread Ben Cooksley
On Sat, Feb 8, 2020 at 10:20 AM David Faure  wrote:
>
> On vendredi 7 février 2020 19:03:35 CET Ben Cooksley wrote:
> > Hi all,
> >
> > Recently i've observed that a dependency build has started to fail
> > (along with some other Binary Factory builds) due to the following
> > message:
> >
> > CMake Error at
> > /usr/home/jenkins/install-prefix/share/ECM/modules/ECMGeneratePriFile.cmake
> > :183 (get_target_property):
> > get_target_property() called with non-existent target "KF5ConfigCore".
> >   Call Stack (most recent call first):
> > src/widgets/CMakeLists.txt:75 (ecm_generate_pri_file)
> >
> > At the moment it seems not all Frameworks are affected, but KPeople
> > definitely is.
>
> There were copy/paste errors in those CMakeLists.txt.
> Nicolas Fella just fixed it.
>
> commit 94a255a820015a25179d35713995503dbb9bcf61 (HEAD -> master, origin/
> master, origin/HEAD)
> Author: Nicolas Fella 
> Date:   Fri Feb 7 19:11:00 2020 +0100
>
> fix pri file generation
>

Awesome, thanks for sorting this Nicolas!

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

Cheers,
Ben


KPeople/ECM/KConfig build regression

2020-02-07 Thread Ben Cooksley
Hi all,

Recently i've observed that a dependency build has started to fail
(along with some other Binary Factory builds) due to the following
message:

CMake Error at 
/usr/home/jenkins/install-prefix/share/ECM/modules/ECMGeneratePriFile.cmake:183
(get_target_property):
get_target_property() called with non-existent target "KF5ConfigCore".
  Call Stack (most recent call first):
src/widgets/CMakeLists.txt:75 (ecm_generate_pri_file)

At the moment it seems not all Frameworks are affected, but KPeople
definitely is.

A more detailed log can be found at
https://build.kde.org/view/Failing/job/Administration/job/Dependency%20Build%20Extragear%20stable-kf5-qt5%20FreeBSDQt5.13/lastFailedBuild/console

Any ideas?

Cheers,
Ben


Re: Banning QNetworkAccessManager

2020-02-03 Thread Ben Cooksley
On Mon, Feb 3, 2020 at 11:51 PM Johan Ouwerkerk  wrote:
>
> On Mon, Feb 3, 2020 at 11:27 AM laurent Montel  wrote:
> >
> > Le lundi 3 février 2020, 10:49:10 CET David Edmundson a écrit :
> > > I updated:
> > >
> > > https://community.kde.org/Policies/API_to_Avoid
> > >
> > > Which had no mention of this.
> > >
> > > David
> >
> > I think that you made an error
> >
> > "networkAccessManger->setAttribute(QNetworkRequest::FollowRedirectsAttribute,
> > true); "
> > Doesn't exist it's a enum from QnetworkRequest::RedirectPolicy
> > And  FollowRedirectsAttribute is old value
> > It seems that we need to use QnetworkRequest::NoLessSafeRedirectPolicy
> > directly no ?
> >
>
> Yes, the example code is definitely wrong: in the real world redirects
> are an attack vector. A few cases to consider:
>
>  * Loops of redirects (could happen if the site is broken)
>  * Leaking sensitive information via e.g. the Referrer header

I would recommend follwoing the various browsers (Firefox & Chromium
in particular) behaviour here.
Not only are they what we generally test redirects with when doing
server maintenance, but they also have put quite a bit of work into
being secure.

With regards to loops, stopping after 10 or so redirects should be
more than sufficient as a safe guard here. 5 if you'd like to be a bit
more restrictive.
I can't imagine a need with our systems to need more than 3 (first to
https, second from somewhere to the mirror network redirector, third
to a mirror)

Because mirrors often don't support https (and Mirrorbrain doesn't
support handling https mirrors) clients that interact with
download.kde.org or files.kde.org *must* support transitioning from
https:// to http:// (under a different domain - so
https://download.kde.org to http://ftp.gwdg.de for instance). This
would primarily affected applications that need to fetch large binary
assets.

>
> Regards,
>
>  - Johan

Cheers,
Ben


Re: Banning QNetworkAccessManager

2020-02-03 Thread Ben Cooksley
On Mon, Feb 3, 2020 at 10:49 PM David Edmundson
 wrote:
>
> I updated:
>
> https://community.kde.org/Policies/API_to_Avoid
>
> Which had no mention of this.

Many thanks for updating the wiki David.

>
> David

Cheers,
Ben


Re: Banning QNetworkAccessManager

2020-02-03 Thread Ben Cooksley
On Mon, Feb 3, 2020 at 7:42 AM Volker Krause  wrote:
>
> I agree on the problem of QNAM's default, see also https://conf.kde.org/en/
> akademy2019/public/events/135 on that subject.
>
> On Saturday, 1 February 2020 23:24:14 CET Ben Cooksley wrote:
> [...]
> > Prior to now, i've taken the approach of advertising that
> > QNetworkAccessManager is broken and needs a flag set within
> > applications when used, however unfortunately this seems to have been
> > an ineffective approach and cases of broken behaviour continue to
> > appear (despite this brokeness being known about and advertised since
> > back in the Qt 4.x series when this class was introduced)
> >
> > Therefore, given the Qt Project is unlikely to change their position
> > on this, I would like to propose the following:
>
> The Qt Project is actually in favor of changing at least the redirection
> default to exactly what we want it to be.
> https://codereview.qt-project.org/c/qt/qtbase/+/273175 has the change, and got
> approval both by Lars and one of the maintainers. It is merely stuck in
> dealing with the unit test fallout in Qt's CI that somebody has to take care
> of. Doesn't immediately help us of course, but claiming Qt is unwilling to
> change this is simply wrong.

Last I heard they were unwilling to change the default, so it's nice
to know they're looking at revisiting their error.

Back when this issue originally developed back in the Qt 4.x era (just
a couple of releases after QNAM appeared) the Qt Developers at the
time not only refused to change the default, but also refused to
consider adding any kind of convenience function. They considered that
their position was the most correct one and that following redirects
simply wasn't required (as it isn't a MUST in the RFCs).

It was later on (around Qt 5.7 I think) that a set of functions and
enums were added to Qt to make it convenient to change the behaviour.
When these were initially introduced the behaviour was changed to
follow redirects, however that was then overturned before it was
released (on the basis of an absolute need for "behavioural
compatibility", something that wasn't an issue when the change went
through initially, so my suspicion is a customer of Digia at the time
threw their toys)

I wasn't involved directly in the conversations in the Qt 5.7
timeframe, so don't have a link to that i'm afraid. The Qt 4.x one was
a conversation on IRC.

While that merge request is promising, it unfortunately is targeted at
the 'dev' branch, which if i'm not wrong is Qt 6.x, so it will be some
time before we get to see the benefit of that (more on that below).

>
> > 1) That effective immediately, QNetworkAccessManager and it's children
> > classes be banned and prohibited within KDE software, to be enforced
> > by server side hooks.
> > 2) That we fork QNetworkAccessManager and the associated classes
> > within the appropriate Framework (to be determined), where the
> > defective behaviour can then be corrected.
>
> While this might solve the redirection problem, it brings us yet another then
> unmaintained HTTP implementation next to the one in KIO, which is a far bigger
> problem long term. We need less of those, not more.
>

It is not ideal I agree.
What I would like to ensure however is that we are not impacted in the
future by any policy decisions made by the Qt Developers in respect of
this set of classes.

> To address the problem of people not using the correct defaults, I did propose
> a much less extreme approach in the above mentioned talk at Akademy, namely
> having a KNetworkAccessManager as a sub-class of QNAM in a low-tier frameworks
> that essentially just enables redirects and HSTS. QNAM's implementation isn't
> the problem after all, the defaults are.
>

This may work, but we would need to force people to move to using the
wrapper, and it still leaves us exposed to anywhere that retrieves a
QNAM constructed by code located elsewhere.

> Commit hooks warning about QNAM usage might still be a good idea, but as a
> warning only. Hard blocking QNAM-using code would block at least three repos I
> spend a lot of time on currently, none of which even talks to KDE servers.
>
> If you need to take more drastic measures against code not doing this
> correctly regardless, you can do that my dropping the server-side workarounds.
> Yes, that would break the affected application possibly, but at least it would
> not cause massive collateral damage for the people using this correctly.
>

Nicolas did a spot check of some of the places where QNAM is used in
KDE, and at first glance it appears that not a single one enabled the
following of redirects :(
It is likely that very few places handle this correctly (probably only
those who have interacted with Sysadmin on the matte

D27028: Switch from download.k.o to autoconfig

2020-02-03 Thread Ben Cooksley
bcooksley added inline comments.

INLINE COMMENTS

> meven wrote in khotnewstuff.knsrc:2
> Shouldn't it be in https ?

Yes, this should be https - the server will redirect to https (which sets HSTS 
headers) in any case.

REPOSITORY
  R304 KNewStuff

REVISION DETAIL
  https://phabricator.kde.org/D27028

To: leinir, bcooksley, #frameworks
Cc: meven, broulik, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, 
bruns


Banning QNetworkAccessManager

2020-02-01 Thread Ben Cooksley
Hi all,

For an extremely long time now, it has been a known issue with the
QNetworkAccessManager that by default it does not follow redirects as
issued by the server it is accessing. This is something the Qt Project
has refused to address using the justification of 'behavioural
compatibility'

This behaviour is contrary to that of just about every other HTTP
stack (with the exception of libcurl from my understanding) and is
behaviour that nobody expects.

As a consequence of this (broken) behaviour, Sysadmin has been
effectively forced to implement workarounds and other compatibility
measures in place to keep applications functional. These measures harm
the long term maintainability of our systems, and sometimes limit our
ability to make services more scalable. In some instances, the cost of
compatibility measures would be too high, resulting in functionality
of applications being broken. I am aware of at least one instance
where if a compatibility measure we maintain is removed, the
application will crash (segfault) during it's operation (a failure
that makes the application unusable)

Prior to now, i've taken the approach of advertising that
QNetworkAccessManager is broken and needs a flag set within
applications when used, however unfortunately this seems to have been
an ineffective approach and cases of broken behaviour continue to
appear (despite this brokeness being known about and advertised since
back in the Qt 4.x series when this class was introduced)

Therefore, given the Qt Project is unlikely to change their position
on this, I would like to propose the following:
1) That effective immediately, QNetworkAccessManager and it's children
classes be banned and prohibited within KDE software, to be enforced
by server side hooks.
2) That we fork QNetworkAccessManager and the associated classes
within the appropriate Framework (to be determined), where the
defective behaviour can then be corrected.

Comments?

Regards,
Ben Cooksley
KDE Sysadmin


  1   2   3   4   5   6   7   8   >