[sysadmin/ci-tooling] system-images/suse-qt515: Strip out all packages relating to Python bindings support from our SUSE CI images.
Git commit 6a92fdf747990d2e074e92b2bdc224efc9b08740 by Ben Cooksley. Committed on 10/11/2021 at 07:37. Pushed by bcooksley into branch 'master'. Strip out all packages relating to Python bindings support from our SUSE CI images. The CMake target dependencies aren't sufficiently setup within the Frameworks for the Python bindings, which means our builds for those Frameworks with complicated bindings - like KConfig - are now highly deterministic. This poses severe issues for our Dependency Builds causing them to fail quite often, making it very difficult to perform maintenance on the CI system. CCMAIL: kde-frameworks-devel@kde.org M +0-2system-images/suse-qt515/Dockerfile https://invent.kde.org/sysadmin/ci-tooling/commit/6a92fdf747990d2e074e92b2bdc224efc9b08740 diff --git a/system-images/suse-qt515/Dockerfile b/system-images/suse-qt515/Dockerfile index 812adb0..02cb243 100755 --- a/system-images/suse-qt515/Dockerfile +++ b/system-images/suse-qt515/Dockerfile @@ -75,8 +75,6 @@ RUN zypper --non-interactive in --allow-vendor-change \ aspell-devel \ hunspell-devel \ libvoikko-devel \ -# Python bindings in Frameworks -python38-qt5-sip python38-qt5-devel python3-sip4 python38-qt5 python38-sip4-devel python3-clang \ # kio-extras and krdc libssh-devel \ # plasma-pa
CI System Issues
Hi all, Over the past 24-48 hours we have been experiencing significant issues with both of the Jenkins' instances which operate build.kde.org and binary-factory.kde.org. After significant investigative work these issues have been traced to a bug/regression within Docker itself, which we have now applied a workaround for. This issue is tracked at upstream bug https://github.com/moby/moby/issues/42375 which unfortunately has received little attention thus far. With the resolution of this issue we've now initiated Global Rebuilds across Jenkins to restore normal service. As a consequence of this it may take several hours for the CI system to attend to builds that have been initiated, including updates to our websites. Due to their unreliability in the build chain I will shortly also be terminating support for building Python bindings on Linux, as they are interfering in the ability of the Dependency Builds - and thus the Global Rebuild - to complete. Apologies for the disruption to service. Thanks, Ben Cooksley KDE Sysadmin
CI System Issues
Hi all, Over the past 24-48 hours we have been experiencing significant issues with both of the Jenkins' instances which operate build.kde.org and binary-factory.kde.org. After significant investigative work these issues have been traced to a bug/regression within Docker itself, which we have now applied a workaround for. This issue is tracked at upstream bug https://github.com/moby/moby/issues/42375 which unfortunately has received little attention thus far. With the resolution of this issue we've now initiated Global Rebuilds across Jenkins to restore normal service. As a consequence of this it may take several hours for the CI system to attend to builds that have been initiated, including updates to our websites. Due to their unreliability in the build chain I will shortly also be terminating support for building Python bindings on Linux, as they are interfering in the ability of the Dependency Builds - and thus the Global Rebuild - to complete. Apologies for the disruption to service. Thanks, Ben Cooksley KDE Sysadmin
CI System Issues
Hi all, Over the past 24-48 hours we have been experiencing significant issues with both of the Jenkins' instances which operate build.kde.org and binary-factory.kde.org. After significant investigative work these issues have been traced to a bug/regression within Docker itself, which we have now applied a workaround for. This issue is tracked at upstream bug https://github.com/moby/moby/issues/42375 which unfortunately has received little attention thus far. With the resolution of this issue we've now initiated Global Rebuilds across Jenkins to restore normal service. As a consequence of this it may take several hours for the CI system to attend to builds that have been initiated, including updates to our websites. Due to their unreliability in the build chain I will shortly also be terminating support for building Python bindings on Linux, as they are interfering in the ability of the Dependency Builds - and thus the Global Rebuild - to complete. Apologies for the disruption to service. Thanks, Ben Cooksley KDE Sysadmin
sub: new to KDE community
Hello! I am SySagar . I am new to the open source community. I want your help. Can you please help me know the community and its work? It will be a great help. Thank you!
KDE CI: Frameworks » ktexteditor » kf5-qt5 SUSEQt5.15 - Build # 488 - Still unstable!
BUILD UNSTABLE Build URL https://build.kde.org/job/Frameworks/job/ktexteditor/job/kf5-qt5%20SUSEQt5.15/488/ Project: kf5-qt5 SUSEQt5.15 Date of build: Wed, 10 Nov 2021 01:17:29 + Build duration: 7 min 18 sec and counting BUILD ARTIFACTS acc/KF5TextEditor-5.88.0.xml JUnit Tests Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot Failed: 0 test(s), Passed: 68 test(s), Skipped: 0 test(s), Total: 68 test(s)Name: projectroot.autotests.src Failed: 2 test(s), Passed: 3 test(s), Skipped: 0 test(s), Total: 5 test(s)Failed: projectroot.autotests.src.vimode.vimode_completionFailed: projectroot.autotests.src.vimode.vimode_keys Cobertura Report Project Coverage Summary Name PackagesFilesClassesLinesConditionalsCobertura Coverage Report75% (21/28)87% (261/300)87% (261/300)69% (35264/51343)51% (16300/32124)Coverage Breakdown by Package Name FilesClassesLinesConditionalsautotests.src98% (42/43)98% (42/43)95% (5848/6164)50% (2502/5016)autotests.src.benchmarks0% (0/1)0% (0/1)0% (0/32)0% (0/6)autotests.src.vimode100% (9/9)100% (9/9)95% (5363/5644)50% (892/1790)src.buffer100% (16/16)100% (16/16)91% (1835/2025)75% (1122/1500)src.completion100% (10/10)100% (10/10)58% (1608/2795)42% (926/2220)src.completion.expandingtree100% (3/3)100% (3/3)41% (190/466)22% (75/342)src.dialogs0% (0/4)0% (0/4)0% (0/893)0% (0/192)src.document100% (4/4)100% (4/4)62% (2075/3322)49% (1509/3090)src.export0% (0/4)0% (0/4)0% (0/139)0% (0/158)src.include.ktexteditor88% (14/16)88% (14/16)91% (248/273)72% (180/250)src.inputmode100% (9/9)100% (9/9)66% (198/298)58% (40/69)src.mode86% (6/7)86% (6/7)34% (351/1047)14% (123/878)src.part0% (0/1)0% (0/1)0% (0/8)100% (0/0)src.printing0% (0/4)0% (0/4)0% (0/886)0% (0/280)src.render100% (7/7)100% (7/7)77% (964/1258)65% (608/930)src.script100% (16/16)100% (16/16)71% (773/1095)57% (251/440)src.search100%
KDE CI: Frameworks » ktexteditor » kf5-qt5 FreeBSDQt5.15 - Build # 497 - Still Unstable!
BUILD UNSTABLE Build URL https://build.kde.org/job/Frameworks/job/ktexteditor/job/kf5-qt5%20FreeBSDQt5.15/497/ Project: kf5-qt5 FreeBSDQt5.15 Date of build: Wed, 10 Nov 2021 01:17:29 + Build duration: 5 min 22 sec and counting JUnit Tests Name: projectroot Failed: 0 test(s), Passed: 68 test(s), Skipped: 0 test(s), Total: 68 test(s)Name: projectroot.autotests.src Failed: 2 test(s), Passed: 3 test(s), Skipped: 0 test(s), Total: 5 test(s)Failed: projectroot.autotests.src.vimode.vimode_completionFailed: projectroot.autotests.src.vimode.vimode_keys
KF6 meeting notes 2021-11-09
https://phabricator.kde.org/T12101 * we want QKeyChain as the consumer API (port in progress) * there's a pending merge request to add secret service API to KWallet -> move to in progress https://invent.kde.org/frameworks/purpose/-/issues/1 * Purpose has a very generic API, but currently only used for sharing * Proposal is to change from a generic API to a specific API for sharing only, which would simplify cross-platform support. * How does sharing work with Flatpak? ** For sharing out of a Flatpak: some plugins work, some need extra work (such as those calling CLI tools from external packages). ** For sharing into a Flatpak app: Could be specified in the desktop file and passed as a URL. signature.asc Description: This is a digitally signed message part.
Re: How do you label code to be deleted in KF6?
Am Dienstag, 9. November 2021, 03:33:44 CET schrieb Glen Ditchfield: > I would like to have some members of KCalendarCore's incidence classes > removed during the transition from KF5 to KF6, and I'd like to be sure > that the changes won't be missed in the excitement. > > Do you have some preferred way to label such changes? For example, is > there some `#if` statement that can be wrapped around the code, such > that it will be compiled into KF5 but compiled out of KF6? See https://community.kde.org/Policies/Library_Code_Policy#Deprecation_of_API which should help to get you started with such work. Please extend the docs when you run into unanswered things or would have some use-case where some ready-to-copy samples would be good to have. Cheers Friedrich
Re: How do you label code to be deleted in KF6?
On 09/11/2021 09:26, Ahmad Samir wrote: On 11/9/21 04:33, Glen Ditchfield wrote: I would like to have some members of KCalendarCore's incidence classes removed during the transition from KF5 to KF6, and I'd like to be sure that the changes won't be missed in the excitement. Do you have some preferred way to label such changes? For example, is there some `#if` statement that can be wrapped around the code, such that it will be compiled into KF5 but compiled out of KF6? Hello. We use deprecation macros, grep for DEPRECATED in any KF repo, and see the manual pages for those macros (defined by extra-cmake-modules), lots of examples in the repos already. You can wrap it in the deprecation macros, but a '// TODO KF6 remove' will do too
Re: How do you label code to be deleted in KF6?
On 11/9/21 04:33, Glen Ditchfield wrote: I would like to have some members of KCalendarCore's incidence classes removed during the transition from KF5 to KF6, and I'd like to be sure that the changes won't be missed in the excitement. Do you have some preferred way to label such changes? For example, is there some `#if` statement that can be wrapped around the code, such that it will be compiled into KF5 but compiled out of KF6? Hello. We use deprecation macros, grep for DEPRECATED in any KF repo, and see the manual pages for those macros (defined by extra-cmake-modules), lots of examples in the repos already. -- Ahmad Samir
