Re: Information regarding upcoming Gitlab Migration

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 >

Re: Information regarding upcoming Gitlab Migration: clarifications

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 to

Re: Information regarding upcoming Gitlab Migration

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

Re: Information regarding upcoming Gitlab Migration: clarifications

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 the

Re: Information regarding upcoming Gitlab Migration: clarifications

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 t

Re: Information regarding upcoming Gitlab Migration: clarifications

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

Re: Information regarding upcoming Gitlab Migration

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

Re: Information regarding upcoming Gitlab Migration

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

Re: Information regarding upcoming Gitlab Migration

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

Re: Information regarding upcoming Gitlab Migration

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 Com

Re: Information regarding upcoming Gitlab Migration

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

Re: Information regarding upcoming Gitlab Migration

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

Re: Information regarding upcoming Gitlab Migration

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 mislead

Re: Information regarding upcoming Gitlab Migration

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 >

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

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 >

D6794: assert the testpackage appstream data validates

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

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

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

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

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

D6794: assert the testpackage appstream data validates

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

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

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 Pla

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

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

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

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

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

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

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

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

Re: Update on Status of Gitlab Migration

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

Re: Update on Status of Gitlab Migration

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

Re: Update on Status of Gitlab Migration

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 th

Re: Update on Status of Gitlab Migration

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

Re: Update on Status of Gitlab Migration

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.

Re: Update on Status of Gitlab Migration

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

Notice of upcoming changes to the behaviour of the anongit network

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

f 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

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 is

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

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

D25660: Decouple KBookmarksMenu from KActionCollection

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

D25660: Decouple KBookmarksMenu from KActionCollection

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, #fram

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

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

D27986: Allow providing an error message from the application

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

D27855: [Debug] Improve readability of positioninfo debug format

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

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

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:

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

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)

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

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

D27893: Use fallback also on Windows not only mac

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

Re: kreversi 19.12 fails to build at IconSize call

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

D27355: POC: Make kstatusnotifieritem available without dbus

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

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

Re: Banning QNetworkAccessManager

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 M

Re: Fixing QNetworkAccessManager use

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 >

Re: Fixing QNetworkAccessManager use

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

Re: Banning QNetworkAccessManager

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/

Re: Banning QNetworkAccessManager

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

Re: 2 kirigami fixes for a point release

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 dimecre

Re: 2 kirigami fixes for a point release

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

Re: 2 kirigami fixes for a point release

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

Re: 2 kirigami fixes for a point release

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

Re: 2 kirigami fixes for a point release

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

Re: 2 kirigami fixes for a point release

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 br

Re: 2 kirigami fixes for a point release

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

D27355: POC: Make kstatusnotifieritem available without dbus

bcooksley added inline comments. INLINE COMMENTS > kstatusnotifieritem.cpp:48 > + > +#include > #include New header? > kstatusnotifieritem.cpp:617 > void KStatusNotifierItem::showMessage(const QString &title, const QString > &message, const QString &icon, int timeout) > { > #ifdef Q_OS_M

Re: KPeople/ECM/KConfig build regression

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 build

KPeople/ECM/KConfig build regression

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() c

Re: Banning QNetworkAccessManager

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

Re: Banning QNetworkAccessManager

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

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

D27028: Switch from download.k.o to autoconfig

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

Banning QNetworkAccessManager

de 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

Re: Get Hot New Stuff - Legacy Endpoints and Multiple Requests (Discover?)

d information from the "Details" pane as to why KIO refuses to trust connections to autoconfig.kde.org on your system. Cheers, Ben > > On Thu, Jan 30, 2020, 4:20 AM Ben Cooksley wrote: >> >> Hi all, >> >> While diagnosing an issue this evening with cdn.kde.

Get Hot New Stuff - Legacy Endpoints and Multiple Requests (Discover?)

Hi all, While diagnosing an issue this evening with cdn.kde.org, I noticed that we are still getting an extremely large number of requests for the legacy OCS/GHNS providers.xml endpoint, which is supposed to only exist for compatibility with older applications. Looking on LXR i've found that a su

Fwd: KDE CI: Administration » Dependency Build Applications stable-kf5-qt5 FreeBSDQt5.13 - Build # 49 - Still Failing!

Hi all, Any ideas why this would have suddenly started to fail like this in KHTML? >From what I can see there haven't been any changes in KHTML itself, so this would have to be a regression in another Framework/ECM... (This isn't FreeBSD specific either, as a Linux build just tripped up on the ex

D26752: ECMAddAppIcon: Do not warn about mac and window icons if isnt a OS specific build

bcooksley requested changes to this revision. bcooksley added a comment. Christophe is correct here, it is worth warning developers about these issues regardless of the platform, so they can get the code ready for those platforms and test everything in their local environment as much as possi

D26202: Refactor KConfigXT

bcooksley added a comment. I can confirm that force pushes are blocked within KDE Git repositories, although we will be opening up `work/` branches at some point which will permit it (and be un-notified in terms of hook processing) REPOSITORY R237 KConfig BRANCH rework_kconfig_compiler

KUrlPixmapProvider & kdelibs4support

Hi all, Recently there have been some changes to deprecate parts of KUrlPixmapProvider - changes that appear to have landed in the last 24 hours. Unfortunately this has caused breakage in kdelibs4support as shown by the current status of several Dependency Builds on all platforms. See https://b

D26652: Unbreak module imports for Python2

bcooksley added inline comments. INLINE COMMENTS > frameworkdb.py:39 > +else: > +import kapidox.depdiagram.gvutils > +from kapidox.depdiagram.framework import Framework This probably needs to be `import gvutils from kapidox.depdiagram` otherwise any calling code will need to be `kapidox

Re: Fwd: KDE CI: Administration » Dependency Build Frameworks kf5-qt5 SUSEQt5.12 - Build # 66 - Still Failing!

On Fri, Jan 10, 2020 at 9:39 AM Friedrich W. H. Kossebau wrote: > > Am Donnerstag, 9. Januar 2020, 21:10:23 CET schrieb Ben Cooksley: > > Hi all, > > > > Please see the below Dependency Build failure, which happens on both our Qt > > 5.12 and Qt 5.13 images. &

[sysadmin/ci-tooling] build-specs/Frameworks: Don't build QCH files for KDeclarative due to breakage in Doxygen.

Git commit a193f9562032cfdb4f338c996ab2c7519a516ecf by Ben Cooksley. Committed on 10/01/2020 at 00:09. Pushed by bcooksley into branch 'master'. Don't build QCH files for KDeclarative due to breakage in Doxygen. CCMAIL: kde-frameworks-devel@kde.org A +2-0build-s

Fwd: KDE CI: Administration » Dependency Build Frameworks kf5-qt5 SUSEQt5.12 - Build # 66 - Still Failing!

Hi all, Please see the below Dependency Build failure, which happens on both our Qt 5.12 and Qt 5.13 images. It appears that for reasons unknown, the QCH generation for KDeclarative fails in our newly rebuilt images (it also seems that CMake doesn't pick this up, as it fails at install rather than

Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)

On Mon, Dec 30, 2019 at 3:03 AM Stephen Kelly wrote: > > > On 28/12/2019 23:30, Friedrich W. H. Kossebau wrote: > > Why are you proposing to do a step back instead to the old state, which > > everyone including you considered not that satisfying? > > Because it's a temporary situation. We still ha

[sysadmin/repo-metadata] projects/kdereview/grantlee: Strip Grantlee of it's KDE Git repository and therefore terminate it's status as a KDE project.

Git commit 510628f46bf2ecc6cba15e6940ca1bf3e941224c by Ben Cooksley. Committed on 09/01/2020 at 09:39. Pushed by bcooksley into branch 'master'. Strip Grantlee of it's KDE Git repository and therefore terminate it's status as a KDE project. Ref T12387 CCMAIL: kde-core-de...

D21783: Show more details in warning dialog shown before starting a privileged operation

bcooksley added a comment. This changes FTBFS - see https://build.kde.org/job/Administration/job/Dependency%20Build%20Applications%20kf5-qt5%20SUSEQt5.12/47/ There are currently a large number of Dependency Builds underway to correct changes in the tree as a consequence of Grantlee changing

D23205: [KProcessList] Optimize KProcessList::processInfo

bcooksley added a comment. This broke the build on FreeBSD - See https://build.kde.org/view/Failing/job/Frameworks/job/kcoreaddons/job/kf5-qt5%20FreeBSDQt5.13/lastFailedBuild/console REPOSITORY R244 KCoreAddons REVISION DETAIL https://phabricator.kde.org/D23205 To: hallas, davidedmundso

D13541: Port solid from Qt5::Widgets to Qt5::Gui

bcooksley added a comment. This broke the build on FreeBSD - Please see https://build.kde.org/job/Frameworks/job/solid/job/kf5-qt5%20FreeBSDQt5.13/43/ REPOSITORY R245 Solid REVISION DETAIL https://phabricator.kde.org/D13541 To: graesslin, #frameworks, dhaumann, apol, broulik Cc: bcooksl

[kconfigwidgets] autotests: Revert "GIT_SILENT: remove which includes all of (scripted)"

Git commit 998ea068274ca4ce78903d18ea9afbbad6a67528 by Ben Cooksley. Committed on 14/12/2019 at 17:36. Pushed by bcooksley into branch 'master'. Revert "GIT_SILENT: remove which includes all of (scripted)" This change breaks the build within the autotests for KConfigWidge

D25682: [WIP] add initial wsdiscovery support

bcooksley added a comment. With regards to the Docker/Gitlab CI part, please use the images under kdeorg/ on Dockerhub rather than personally maintained images as the wider community has no access to your namespace on Gitlab.com (Additionally please note that Fedora is not permitted to b

D25720: Fix shortcut conflict between Cut and Delete File

bcooksley added a comment. Shift+Delete is a widely known shortcut combination for "Delete File Immediately, do not send to the Recycle Bin" REPOSITORY R237 KConfig REVISION DETAIL https://phabricator.kde.org/D25720 To: ngraham, #frameworks, cfeck Cc: bcooksley, davidedmundson, aacid, a

Re: KDE CI: Frameworks » kcalendarcore » kf5-qt5 FreeBSDQt5.13 - Build # 29 - Still Unstable!

On Sun, Dec 1, 2019 at 7:34 AM Alexander Potashev wrote: > Hi Ben, > Hi Alexander, > > KCalendarCore's unit tests are failing all the time on FreeBSD CI. Could > you please check if perl interpreter needs to be installed? > Perl is definitely installed, however FreeBSD is a bit different to L

[sysadmin/repo-metadata] projects/frameworks/kquickcharts: Move KQuickCharts into Frameworks.

Git commit 81bc7c68537639a739d0f89f103a1c26b61d by Ben Cooksley. Committed on 29/11/2019 at 18:49. Pushed by bcooksley into branch 'master'. Move KQuickCharts into Frameworks. Ref T12022 CCMAIL: kde-frameworks-devel@kde.org CCMAIL: kde-core-de...@kde.org R +0-0projects/

D25446: [kcoredirlister] Port away from QLinkedList

bcooksley added a comment. This change is incompatible with Qt 5.12 - see https://build.kde.org/view/Failing/job/Frameworks/job/kio/job/kf5-qt5%20SUSEQt5.12/326/ REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D25446 To: nicolasfella, #frameworks, dfaure Cc: bcooksley, d

D21660: remove dbus for windows build and change audio dep logic

bcooksley added a comment. Considering that D-Bus doesn't really belong on Windows, and has been known to cause security software (such as anti-malware packages) to generate false positives in the past, we really should avoid D-Bus completely if at all possible on Windows. For standalone app

D21660: remove dbus for windows build and change audio dep logic

bcooksley added a comment. If tests launch D-Bus Daemon, then they will cause the CI system to jam as CTest will wait indefinitely for dbus-daemon to exit. D-Bus should not be used under any circumstances on Windows. REPOSITORY R289 KNotifications REVISION DETAIL https://phabricator

Re: Disabling of 'kdav-davitemfetchjob' test in KDav

On Sat, Nov 16, 2019 at 11:49 PM Volker Krause wrote: > > On Saturday, 16 November 2019 11:26:39 CET Volker Krause wrote: > > On Saturday, 16 November 2019 07:04:57 CET Ben Cooksley wrote: > > > Hi everyone, > > > > > > Currently we have an issue where

Disabling of 'kdav-davitemfetchjob' test in KDav

Hi everyone, Currently we have an issue where the test 'kdav-davitemfetchjob' within kdav causes kdeinit5 to be relaunched, as can be seen in the CI run log below. https://build.kde.org/job/Applications/job/kdav/job/kf5-qt5%20SUSEQt5.12/38/console This is behaviour which is not permitted within

Windows CI Breakages

Hi all, Apologies for the recent crop of CI failures on Windows. These were caused by Windows Defender's engine eating a significant proportion of the system memory (to the extent the builders were swapping to disk even though they have 24GB of RAM available to them) I have now rebooted the buil

Re: Notice of intention to remove tests from KCrash and KNotifications

On Thu, Nov 7, 2019 at 1:18 AM Harald Sitter wrote: > > On Wed, Nov 6, 2019 at 8:07 AM Ben Cooksley wrote: > > > > On Tue, Nov 5, 2019 at 11:50 PM Harald Sitter wrote: > > > > > > I get where you are coming from, but honestly, none of this makes > > >

Re: Notice of intention to remove tests from KCrash and KNotifications

en if the commit that puts that in effect is CC'ed to the project mailing list, which means that nobody will notice when the tests break because the CI system won't be running them) Regards, Ben > > On Tue, Nov 5, 2019 at 11:24 AM Ben Cooksley wrote: > > > > On Tue, No

Re: Notice of intention to remove tests from KCrash and KNotifications

than 5 minutes. > > > I understand that there's an element of cat herding in this, but > > > quality must matter for our products, and the quality of frameworks is > > > very tightly linked to autotesting and reviews because of how we > > > release them. > > > >

Re: Notice of intention to remove tests from KCrash and KNotifications

f any form to projects that fail to take corrective action (for all platforms). Regards, Ben > > On Tue, Nov 5, 2019 at 10:24 AM Ben Cooksley wrote: > > > > On Tue, Nov 5, 2019 at 1:20 AM Harald Sitter wrote: > > > > > > Wouldn't the more appro

Re: Notice of intention to remove tests from KCrash and KNotifications

e necessary changes (and nobody has taken action when I have mentioned these tests as causing issues) disabling the tests everywhere is the simplest path forward and allows the CI system to operate correctly for everyone rather than be disrupted by these two offending tests. Cheers, Ben > > On Mo

Re: Notice of intention to remove tests from KCrash and KNotifications

On Mon, Nov 4, 2019 at 10:53 PM David Edmundson wrote: > > Given kcrashtest passes locally, can you please confirm that by > "remove" you mean disable and not remove. I mean remove. This test is highly dangerous and enters into a fork loop on Windows, necessitating use of an administrator level

Notice of intention to remove tests from KCrash and KNotifications

27;KNotificationTest' (executable at fault: dbus-daemon.exe) in KNotifications These issues have previously been raised, and as unfortunately no solution has yet been found, the only option now is to remove these tests from the codebase. Regards, Ben Cooksley KDE Sysadmin

D24665: Use ECMGenerateExportHeader to manage deprecated API better

bcooksley added a comment. I've now removed the Staging Area URI for the KArchive repository, so you should now be able to use Arcanist with it again. REPOSITORY R243 KArchive REVISION DETAIL https://phabricator.kde.org/D24665 To: kossebau, #frameworks, dfaure Cc: bcooksley, kde-framewo

<    1   2   3   4   5   6   7   8   9   10   >