Re: RFC: an improved ki18n_install
On 2023-03-07 13:12, Friedrich W. H. Kossebau wrote: Am Dienstag, 7. März 2023, 02:51:06 CET schrieb Aleix Pol: Having ninja/make do this dependency generation can end up being more work than worth it because then we need to have a static list Such static list could be generated by scripty when it updates the po/ folder and stored there, no? Which then could be sourced by the ki18n_install cmake code in some way. That sounds like a good solution, one could just emit some CMake file to include that contains the call to the ki18n_install helper with the right args, then on the outside one would just need to add the po dir and be done. Greetings Christoph I'd urge to use the existing tools like make/ninja as much as possible instead of reimplementing their logic partially and maintaining a non-integrated sub buildsystem, with all the shortcomings and fails. Thanks for working on this in any case, the current state is far from ideal. -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: portings aids in kf6?
On 2023-01-25 16:56, Jonathan Riddell wrote: Can the team say which, if any, porting aids will continue in kf6? KDELibs4Support KDesignerPlugin KDEWebKit KHtml KJS KJsEmbed KMediaPlayer Kross KXmlRpcClient I would assume none of them that are marked as deprecated: true in the metainfo.yaml Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: KF5 branches
On 2023-01-08 00:00, David Edmundson wrote: There is now a "kf5" branch in all frameworks repos as discussed last frameworks meeting. Starting now any commits that are also wanted in the next KF5 should be cherry-picked after landing. This does *not* mean master is fully open for going into KF6 dev mode. Now the kf5 branches exist, we'll set up tooling and infrastructure and make sure that is all stable. Only after that is all sorted should master start getting any Qt6-exclusive dev work and version bumps. Hi, thanks for setting that up, let's get some great Qt 6 based release out this year. Greetings Christoph Regards David -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: Telemetry in Plasma and Discover
On 2022-07-13 06:03, Luca Beltrame wrote: In data martedì 12 luglio 2022 16:52:21 CEST, Nate Graham ha scritto: Hello Nate, +Fabian Vogt and Luca Beltrame specifically Thanks, that's a relief! Does this looks legit enough for openSUSE to stop patching out the KUSerFeedback integration? In principle I do not have any objections given the thread, but I'd also like input from Christophe (added to CC). As an aside I see that similar messages were sent out for PIM and other applications. That might be enough to re-enable things everywhere. Hi, at least for Kate & KWrite I would hope we followed the rules by the letter, with a merge request and the mandatory mail. Therefore I would love to see that people are able to activate the telemetry and it not being patched out (if that is the case ATM). If it is patched out ATM, I would have appreciated some notification that we did something wrong, then we could have rectified it. Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: New cmake warning.
On 2022-05-16 19:38, Alexander Neundorf wrote: On Dienstag, 3. Mai 2022 18:43:48 CEST Méven wrote: Le mar. 3 mai 2022 à 18:25, Thomas Friedrichsmeier < thomas.friedrichsme...@kdemail.net> a écrit : > On Tue, 3 May 2022 10:35:20 +0200 > > Méven wrote: > > I am guessing you are using cmake >= 3.16 so it allows you to run, but > > since the project does not have a cmake minimum, for others using > > cmake < 3.16 the build will break. > > This warning highlights it, so you inform your contributor they need > > cmake 3.16 before running into the hard fail in FindKF5. > > On the downside, project wishing to remain backwards-compatible with > older systems (which will come with older versions of both cmake and > ECM) will want to avoid adding such a requirement, explicitly. Cmake 3.16 dates from November 2019 to put things in perspective. RHEL 8, which many commercial users have not updated to yet, comes with cmake 3.11, to add some more perspective ;-) Yeah, that is true, but to be realistic: We do commercial software development and even need to stick with RHEL 7 and we do what everybody else does: Just install a proper cmake during both the CI and the normal development. We even install our own compilers or at least the latest devtoolset, otherwise RHEL 7 is useless. I don't think the enterprise distros are anything we should really look at for determining our dependency versions. Greetings Christoph Alex -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: Git merge workflow: reverse it?
On 2022-05-10 15:33, Nate Graham wrote: On 5/10/22 04:15, Ingo Klöcker wrote: https://manifesto.kde.org/commitments/ I don't see anything in there that would force the same merge workflow on all KDE projects. In my view the merge workflow is comparable to the coding style. Regards, Ingo I don't think anyone is trying to force anything; rather, the proposal is to get voluntary consensus around standardizing on a single workflow (whatever it is) so that we all individually reap the benefits of consistency by not having to remember two workflows, look up which workflow a project uses, etc. Personally I don't care which one we standardize on, but I am in favor of voluntarily and communally standardizing on one of them. Yeah, I doubt we can or want to force people. I personally prefer the cherry-pick approach from master to the stable branch(es), given I only work on the master branch and that is for me the best way to previously test the stuff properly. Naturally for e.g. Kate we only backport trivial stuff that way. Greetings Christoph Nate -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
KUserFeedback integration for KWrite
Hi, we will change KWrite to re-use the Kate codebase. As side-effect, KWrite will like Kate now support opt-in telemetry via KUserFeedback (can be even deactivated fully during compile time, purely optional dependency). The code is the same as used in Kate, the relevant merge request for the unification is: https://invent.kde.org/utilities/kate/-/merge_requests/692 This will happen soon in master, if reviewed & ok'd, the first release with this will be 22.08. This will then be documented as needed on https://community.kde.org/Telemetry_Use If you have feedback, please refer to the above merge request. Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: Please fix failing unit tests with Windows platform
On 2022-01-24 01:32, Friedrich W. H. Kossebau wrote: Am Montag, 24. Januar 2022, 01:22:05 CET schrieb Albert Astals Cid: Are you going to propose the same for Linux and FreeBSD where we also have long running tests that don't succeed and no one bothers to fix them? Yes, if a test is known to fail, and no solution is known, it should be tagged as EXPECT_TO_FAIL. Is there would be projects that do not do that (e.g. if the maintainer only cares for Windows, to turn things around), for those platforms where tests keep failing eternally unhandled we should drop the claim of support (and wasting CI resources). I can take a look at some tests on Windows. But I would prefer to do so after we actually use the new GitLab CI. And yes, I agree, that it should be the goal to have no failing tests on all platforms we have a CI for. Greetings Christoph Cheers Friedrich -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: Gitlab CI for Windows
On 2022-01-04 20:23, Ben Cooksley wrote: On Wed, Jan 5, 2022 at 6:36 AM Christoph Cullmann (cullmann.io [1]) wrote: On 2022-01-04 18:24, Ben Cooksley wrote: Hi all, Next update in this saga appears to be a defect in KDeclarative, which apparently has a hard dependency on KGlobalAccel. https://invent.kde.org/sysadmin/ci-management/-/jobs/195039 While this is something that we have previously built on Windows, from my understanding it is essentially a no-op that does nothing so we should probably skip building it. Can someone please take a look into this and advise whether KDeclarative can also make it optional? Hi, I can take a look. If you could, that would be much appreciated. Nicolas was faster :=) I would assume master should already build. I have some additional small patch here https://invent.kde.org/frameworks/kdeclarative/-/commit/7200ad3d518f199ac040afcaf8d3330fd3f79ab7 Btw., it seems the unit tests fail in the classic CI. Is it possible that some data/ dir is created in bin/ for Windows? This seems to confuse the auto tests where to find their input. Greetings Christoph Greetings Christoph Cheers, Ben Thanks, Ben On Tue, Jan 4, 2022 at 7:51 AM Ben Cooksley wrote: On Mon, Jan 3, 2022 at 9:00 AM Ben Cooksley wrote: Hi all, Over the past few days substantial progress has been made in getting Windows builds running under Gitlab, to the point where some Frameworks are now successfully compiling. Unfortunately we've run into a little issue with breeze-icons as can be seen at https://invent.kde.org/sysadmin/ci-management/-/jobs/193039 Following investigation and some testing by Harald we've confirmed that this is a CMake bug - with it being unable to handle symlinks on Windows correctly. For now I shall workaround the issue by disabling use of symlinks on Windows in Git (git config --system core.symlinks false) however that is not an ideal long term fix. Do we have any contacts at CMake we can escalate this bug to? As for why this didn't show up earlier - it seems our Windows builders for Jenkins have symlinks disabled (indicating that either the feature was still too experimental back then or that we did hit this back then and worked around it then as well) Any ideas? Thanks, Ben Cheers, Ben -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org Links: -- [1] http://cullmann.io -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: Gitlab CI - Inbound
On 2021-09-06 11:48, Ben Cooksley wrote: On Mon, Sep 6, 2021 at 9:00 PM Tom Zander wrote: On zondag 5 september 2021 08:13:09 CEST Ben Cooksley wrote: In terms of the format of the 'Dependencies' section, Playing with kde-build script and noticing the fast growing dependency trees we have today, I think it may be beneficial to have two types of compile dependencies in this setup. 1. required-to-build. Which means that if something in the parent tree changes, this one is scheduled for re-build. 2. optional. Equivalent of the cmake feature, if its not there some code is not compiled. At least once before a release the full dependencies can be compiled to see if it fully compiles. From the perspective of the CI system there is basically no difference in terms of making a dependency available or not as all dependencies are always satisfied using previously built binaries. If a dependency is not available your build fails. We also have to make a hard choice - we either bring in optional dependencies or we don't. If we were to randomise whether we brought them in - or just brought them in at certain times - then we would make the system state deterministic. This could in some cases cause builds to break if it was random whether or not we included optional dependencies. This would occur if the dependency of a dependency of a project were rebuilt without an optional dependency being present which in turn caused it's API interface to change. That would then cause the project to fail as the dependency would now be broken. Pushing everything into required is likely not scalable, causing projects too wait too long for compile. Avoiding the optional ones means you lack coverage of compile and testing failures due to changes in libs. The CI system has reused the results of previous builds of dependencies since the very first generation of the system (this would be generation 5) so this is not a problem facing the CI system. For individual developers, my understanding is that kdesrc-build makes use of incremental builds which eliminates most of the issue as well. What do people think, is it useful to have an 'optional' category in future there? Maybe useful to think that far ahead now people are populating their dependencies :-) Hi, I would prefer to not have some optional category to be sure the CI always builds with the same state of dependencies, too. Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: Gitlab CI - Inbound
On 2021-09-06 11:48, Ben Cooksley wrote: On Mon, Sep 6, 2021 at 9:00 PM Tom Zander wrote: On zondag 5 september 2021 08:13:09 CEST Ben Cooksley wrote: In terms of the format of the 'Dependencies' section, Playing with kde-build script and noticing the fast growing dependency trees we have today, I think it may be beneficial to have two types of compile dependencies in this setup. 1. required-to-build. Which means that if something in the parent tree changes, this one is scheduled for re-build. 2. optional. Equivalent of the cmake feature, if its not there some code is not compiled. At least once before a release the full dependencies can be compiled to see if it fully compiles. From the perspective of the CI system there is basically no difference in terms of making a dependency available or not as all dependencies are always satisfied using previously built binaries. If a dependency is not available your build fails. We also have to make a hard choice - we either bring in optional dependencies or we don't. If we were to randomise whether we brought them in - or just brought them in at certain times - then we would make the system state deterministic. This could in some cases cause builds to break if it was random whether or not we included optional dependencies. This would occur if the dependency of a dependency of a project were rebuilt without an optional dependency being present which in turn caused it's API interface to change. That would then cause the project to fail as the dependency would now be broken. Pushing everything into required is likely not scalable, causing projects too wait too long for compile. Avoiding the optional ones means you lack coverage of compile and testing failures due to changes in libs. The CI system has reused the results of previous builds of dependencies since the very first generation of the system (this would be generation 5) so this is not a problem facing the CI system. For individual developers, my understanding is that kdesrc-build makes use of incremental builds which eliminates most of the issue as well. What do people think, is it useful to have an 'optional' category in future there? Maybe useful to think that far ahead now people are populating their dependencies :-) Hi, I would prefer to not have some optional category to be sure the CI always builds with the same state of dependencies, too. Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
