Re: KStars: Cannot change language
On Freitag, 21. Juni 2024 10:31:50 CEST Jasem Mutlaq wrote: > We have an issue with the recent versions of KStars is that language cannot > be switched by users. This affects MacOS, Windows, and Linux, whether > packaged or built from source. > > How to debug this issue? I can't see anything in the logs about the > language switch issue. For example, I tried changing the language to German > but the interface is still in English. Which component of KDE Frameworks is > handling this at the backend? Any environment variables to check or watch > out for? > > Any pointers would be appreciated. On Sonntag, 2. Juni 2024 13:36:58 CEST I wrote in reply to your previous message with subject "Re: Cannot change language": I have just built the current master version (which calls itself 3.7.1 Stable) with KDE Frameworks 5.115.0 and Qt 5.15.12 (on openSUSE Tumbleweed). I could switch the language (via Help -> Configure Language) to different languages. I have built kstars without the optional dependencies INDI, Nova, ERFA, LibRaw, LibXISF, Qt5Keychain. Maybe one of those dependencies messes with the LANGUAGE environment variable that KDE Frameworks use for overriding the system language. Or Qt 5.15.13 is messed up. === Did you try building kstars without optional dependencies to verify my observation that with such a build changing the language works? Two KDE Frameworks are involved in changing the language. KXMLGui provides the language switching dialog. Moreover it loads the configured language and sets the environment variable LANGUAGE. KI18n loads the translations for the language(s) in the LANGUAGE variable. On Linux the configured languages are stored in/read from the file ~/.config/klanguageoverridesrc Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (master) (18 June 2024)
On Freitag, 21. Juni 2024 00:36:45 CEST Albert Astals Cid wrote: > El dimecres, 19 de juny del 2024, a les 9:07:50 (CEST), Ingo Klöcker va > > escriure: > > On Mittwoch, 19. Juni 2024 00:49:14 CEST Albert Astals Cid wrote: > > > kdenlive - 2nd week > > > > > > * https://invent.kde.org/multimedia/kdenlive/-/pipelines/716283 > > > > > > * craft_appimage_qt6_x86_64 fails > > > > > > isoimagewriter - NEW > > > > > > * https://invent.kde.org/utilities/isoimagewriter/-/pipelines/716655 > > > > > > * craft_appimage_qt6_x86_64 fails > > > > > > neochat - NEW > > > > > > * https://invent.kde.org/network/neochat/-/pipelines/716759 > > > > > > * craft_appimage_qt6_x86_64 fails > > > > All of these fail because the tests of kconfig don't build. I'm wondering > > why not all AppImage builds of all projects fail. > > > > The cause for the failing (or highly unstable) builds of the tests of > > kconfig is an error in the test design. Here's what I wrote late last > > night > > in #kde-craft:kde.org. > > > > === > > There is a pair of tests, e.g. Test8 and Test8_cmake where the latter is > > supposed to test that cmake can generate a .kcfgc file. The problem is > > that > > both tests share the same test8main.cpp which includes a test8a.h. This > > test8a.h is generated via test8a.kcfg[c] for Test8, but for Test8_cmake > > test8a_cmake.h is generated via a test8a_cmake.kcfg[c]. If for some reason > > Test8_cmake is built before Test8 then test8main.cpp doesn't find > > test8a.h. > > I'm not yet sure how to fix this. Maybe we need to create patched copies > > of > > testXmain.cpp which includes a testXx_cmake.h instead of a testXx.h. Or > > maybe we put both tests in separate subdirs and don't append _cmake to the > > files used for the TestX_cmake tests. That's feels like a cleaner solution > > also because it better isolates the two tests from each other. > > === > > > > With make the problem doesn't seem to occur because it looks like the > > Makefiles serialize building of Test8 and Test8_cmake so that Test8_cmake > > is always built after Test8 where Test8 creates the headers that > > Test8_cmake uses. With ninja the builds of both targets don't seem to be > > serialized so that Test8_cmake could be built before Test8. -> Fail! > > With that info, we got a fix in, but that won't fix CI since it uses > tarballs, should we get > https://invent.kde.org/frameworks/kconfig/-/merge_requests/314/diffs > added as a patch to Craft? In the meantime building of the KConfig tests has been disabled in Craft. We can just wait for KF 6.4. Actually, I'm wondering why we build tests in Craft at all. Craft doesn't run the tests, the tests are not packaged _and_ the purpose of the Craft jobs isn't CI. I'd say we should probably disable building of tests in general in Craft. Building them is just a waste of energy and time and I fail to see any benefit. When/if we want to start running the tests in Craft then we can simply re-enable their build. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (master) (18 June 2024)
On Mittwoch, 19. Juni 2024 11:54:46 CEST Ben Cooksley wrote: > On Wed, Jun 19, 2024 at 7:07 PM Ingo Klöcker wrote: > > On Mittwoch, 19. Juni 2024 00:49:14 CEST Albert Astals Cid wrote: > > > kdenlive - 2nd week > > > > > > * https://invent.kde.org/multimedia/kdenlive/-/pipelines/716283 > > > > > > * craft_appimage_qt6_x86_64 fails > > > > > > isoimagewriter - NEW > > > > > > * https://invent.kde.org/utilities/isoimagewriter/-/pipelines/716655 > > > > > > * craft_appimage_qt6_x86_64 fails > > > > > > neochat - NEW > > > > > > * https://invent.kde.org/network/neochat/-/pipelines/716759 > > > > > > * craft_appimage_qt6_x86_64 fails > > > > All of these fail because the tests of kconfig don't build. I'm wondering > > why > > not all AppImage builds of all projects fail. > > > > The cause for the failing (or highly unstable) builds of the tests of > > kconfig > > is an error in the test design. Here's what I wrote late last night in > > #kde-craft:kde.org. > > > > === > > There is a pair of tests, e.g. Test8 and Test8_cmake where the latter is > > supposed to test that cmake can generate a .kcfgc file. The problem is > > that > > both tests share the same test8main.cpp which includes a test8a.h. This > > test8a.h is generated via test8a.kcfg[c] for Test8, but for Test8_cmake > > test8a_cmake.h is generated via a test8a_cmake.kcfg[c]. If for some reason > > Test8_cmake is built before Test8 then test8main.cpp doesn't find > > test8a.h. I'm > > not yet sure how to fix this. Maybe we need to create patched copies of > > testXmain.cpp which includes a testXx_cmake.h instead of a testXx.h. Or > > maybe > > we put both tests in separate subdirs and don't append _cmake to the files > > used > > for the TestX_cmake tests. That's feels like a cleaner solution also > > because > > it better isolates the two tests from each other. > > === > > > > With make the problem doesn't seem to occur because it looks like the > > Makefiles > > serialize building of Test8 and Test8_cmake so that Test8_cmake is always > > built after Test8 where Test8 creates the headers that Test8_cmake uses. > > With > > ninja the builds of both targets don't seem to be serialized so that > > Test8_cmake could be built before Test8. -> Fail! > > Interestingly there must be a platform specific part to this, as the CI > system uses Ninja on Windows for those builds. > Either that or we have a newer version of Ninja in Craft that hasn't hit > the CI system yet Turns out that the Windows CI build of kconfig did fail intermittently because of this, e.g. https://invent.kde.org/frameworks/kconfig/-/jobs/1864899 Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (master) (18 June 2024)
On Mittwoch, 19. Juni 2024 00:49:14 CEST Albert Astals Cid wrote: > kdenlive - 2nd week > * https://invent.kde.org/multimedia/kdenlive/-/pipelines/716283 > * craft_appimage_qt6_x86_64 fails > > > isoimagewriter - NEW > * https://invent.kde.org/utilities/isoimagewriter/-/pipelines/716655 > * craft_appimage_qt6_x86_64 fails > > > neochat - NEW > * https://invent.kde.org/network/neochat/-/pipelines/716759 > * craft_appimage_qt6_x86_64 fails All of these fail because the tests of kconfig don't build. I'm wondering why not all AppImage builds of all projects fail. The cause for the failing (or highly unstable) builds of the tests of kconfig is an error in the test design. Here's what I wrote late last night in #kde-craft:kde.org. === There is a pair of tests, e.g. Test8 and Test8_cmake where the latter is supposed to test that cmake can generate a .kcfgc file. The problem is that both tests share the same test8main.cpp which includes a test8a.h. This test8a.h is generated via test8a.kcfg[c] for Test8, but for Test8_cmake test8a_cmake.h is generated via a test8a_cmake.kcfg[c]. If for some reason Test8_cmake is built before Test8 then test8main.cpp doesn't find test8a.h. I'm not yet sure how to fix this. Maybe we need to create patched copies of testXmain.cpp which includes a testXx_cmake.h instead of a testXx.h. Or maybe we put both tests in separate subdirs and don't append _cmake to the files used for the TestX_cmake tests. That's feels like a cleaner solution also because it better isolates the two tests from each other. === With make the problem doesn't seem to occur because it looks like the Makefiles serialize building of Test8 and Test8_cmake so that Test8_cmake is always built after Test8 where Test8 creates the headers that Test8_cmake uses. With ninja the builds of both targets don't seem to be serialized so that Test8_cmake could be built before Test8. -> Fail! Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (master) (4 June 2024)
On Donnerstag, 13. Juni 2024 23:08:43 CEST Elvis Angelaccio wrote:
> On 09/06/24 17:16, Thiago Macieira wrote:
> > The path is correct at the point it is issued, referring to the same
> > directory. The fact that it is in a different form was not expected to be
> > a
> > breaking change.
>
> I had a look at the 6.7 release notes and I've found the commit 935562a77b
> which seems to be what changed this behavior.
>
> Indeed, if I apply the same fix done in that commit to the test-case I
> attached before, i.e. if I replace
>
> auto tempDir = new QTemporaryDir(".test-qtempdir-");
>
> with
> auto tempDir = new QTemporaryDir(QDir::currentPath() + "/.test-
qtempdir-");
>
> then the returned QTemporaryDir::path() goes back to being absolute.
>
> I'd expect at least the QTemporaryDir documentation to get updated with a
> warning about this new behavior. Currently it still claims that
> "Auto-remove mode will automatically delete the directory from disk upon
> destruction.", but this is no longer true if you happened to create the
> QTemporaryDir with a relative template and then change the current
> directory in the process before deleting the QTemporaryDir instance.
That looks like a serious unforeseen regression and was surely not intended.
Best provide a simple test case for QTemporaryDir for this.
Regards,
Ingo
signature.asc
Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (release/24.05) (11 June 2024)
On Freitag, 14. Juni 2024 00:21:41 CEST Albert Astals Cid wrote: > El dijous, 13 de juny del 2024, a les 22:37:04 (CEST), Ingo Klöcker va > > escriure: > > On Mittwoch, 12. Juni 2024 00:22:35 CEST Albert Astals Cid wrote: > > > kwalletmanager - 3rd week > > > > > > * https://invent.kde.org/utilities/kwalletmanager/-/pipelines/711185 > > > > > > * appstream test fails because https://apps.kde.org/kwalletmanager5 > > > > > > doesn't exist > > > > This will be fixed by > > https://invent.kde.org/websites/apps-kde-org/-/merge_requests/94 > > Proof: > > https://invent.kde.org/kloecker/apps-kde-org/-/jobs/1897729/artifacts/ > > external_file/public/kwalletmanager5/index.html > > Can we have someone that knows about that code review it or should i just > press the bottom and YOLO it? [ the html_test on CI fails, is that expected > when run on a repo fork? ] The html_test always fails for MRs. It checks URLs like https://kloecker.local-kde.org/-/apps-kde-org/-/jobs/1897729/artifacts/public/ bovo/ which will never work because unlike on the real page with a real web server there are no redirects to or automatic loading of https://kloecker.local-kde.org/-/apps-kde-org/-/jobs/1897729/artifacts/public/ bovo/index.html Fixed with the following MR which disables the test for all non-protected branches where it will anyway fail https://invent.kde.org/websites/apps-kde-org/-/merge_requests/95 Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (release/24.05) (11 June 2024)
On Mittwoch, 12. Juni 2024 00:22:35 CEST Albert Astals Cid wrote: > kwalletmanager - 3rd week > * https://invent.kde.org/utilities/kwalletmanager/-/pipelines/711185 > * appstream test fails because https://apps.kde.org/kwalletmanager5 > doesn't exist This will be fixed by https://invent.kde.org/websites/apps-kde-org/-/merge_requests/94 Proof: https://invent.kde.org/kloecker/apps-kde-org/-/jobs/1897729/artifacts/ external_file/public/kwalletmanager5/index.html Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (master) (4 June 2024)
On Samstag, 8. Juni 2024 13:40:12 CEST Elvis Angelaccio wrote: > On 04/06/24 22:47, Albert Astals Cid wrote: > > ark - 2nd week > > > > * https://invent.kde.org/utilities/ark/-/pipelines/705069 > > > > * kerfuffle-extracttest fails on FreeBSD > > This test started to fail as soon as we switched from 'freebsd14_qt66' to > 'freebsd14_qt67'. > > I'm afraid this is a regression in Qt 6.7: it seems that > QTemporaryDir::path() no longer returns an absolute path, but a relative > one (which of course can break all sort of things). Are you sure that the test failure is caused by the behavior change in QTemporaryDir? The same test still seems to pass on Linux with Qt 6.7. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (master) (4 June 2024)
On Mittwoch, 5. Juni 2024 20:24:52 CEST Ben Cooksley wrote: > On Wed, Jun 5, 2024 at 7:26 PM Ingo Klöcker wrote: > > In my opinion, the ID of massif-visualizer should be changed back to > > org.kde.massif-visualizer. Or massif-visualizer needs to forgo it's hyphen > > in > > favor of an underscore everywhere to please the appstream folks. For > > details, > > see https://invent.kde.org/websites/apps-kde-org/-/issues/35 > > We've a number of projects that use dashes in their name, so not sure i'm > entirely pleased with the idea that we should be abandoning them. > Do we know how the Appstream folks came to their decision and on what > basis/authority they made that? They have a terrible disregard for the > downstream impact of their decisions... https://github.com/ximion/appstream/issues/162 Interestingly, this issue was filed by our own Nate. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (master) (4 June 2024)
On Dienstag, 4. Juni 2024 22:47:22 CEST Albert Astals Cid wrote: > massif-visualizer - 3rd week > * https://invent.kde.org/sdk/massif-visualizer/-/pipelines/705072 > * appstreamtest fails because https://apps.kde.org/massif-visualizer > doesn't exist > > > kwalletmanager - 2nd week > * https://invent.kde.org/utilities/kwalletmanager/-/pipelines/705070 > * appstreamtest fails because https://apps.kde.org/kwalletmanager5 doesn't > exist https://invent.kde.org/websites/apps-kde-org/-/merge_requests/94 fixes this more or less. With this MR we get https://apps.kde.org/massif_visualizer (which isn't what the appdata claims) and https://apps.kde.org/kwalletmanager5 (which is in line with the appdata) In my opinion, the ID of massif-visualizer should be changed back to org.kde.massif-visualizer. Or massif-visualizer needs to forgo it's hyphen in favor of an underscore everywhere to please the appstream folks. For details, see https://invent.kde.org/websites/apps-kde-org/-/issues/35 Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Cannot change language
On Sonntag, 2. Juni 2024 05:01:33 CEST Jasem Mutlaq wrote: > On Sat, Jun 1, 2024 at 10:08 PM Ingo Klöcker wrote: > > On Montag, 29. April 2024 14:45:17 CEST Jasem Mutlaq wrote: > > > With the release of KStars 3.7.0 a few weeks ago, users are no longer > > > able > > > to switch languages. Once they restart the program, the language remains > > > the system language and cannot be changed. This is new behavior and > > > users > > > complained about it. > > > > > > KStars v3.7.0 is built with KDE Frameworks 5.115.0 and Qt 5.15.13. > > > > > > Is this a bug or regression? > > > > If it worked in previous releases then it looks like a regression. It > > would > > help if you told us on which OSes the problem occurs and/or with which > > installers or packages (e.g. Flatpak). > > The issue occurs on Linux (debian package or built from source) and on > Windows and MacOS. I have just built the current master version (which calls itself 3.7.1 Stable) with KDE Frameworks 5.115.0 and Qt 5.15.12 (on openSUSE Tumbleweed). I could switch the language (via Help -> Configure Language) to different languages. I have built kstars without the optional dependencies INDI, Nova, ERFA, LibRaw, LibXISF, Qt5Keychain. Maybe one of those dependencies messes with the LANGUAGE environment variable that KDE Frameworks use for overriding the system language. Or Qt 5.15.13 is messed up. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (release/24.05) (21 May 2024)
On Dienstag, 21. Mai 2024 23:31:32 CEST Albert Astals Cid wrote: > kate - NEW > * https://invent.kde.org/utilities/kate/-/pipelines/693848 > * craft windows time ran out, did it try to compile the whole world? > * craft mac has been stuck for hours, builder down? > > > dolphin - NEW > * https://invent.kde.org/system/dolphin/-/pipelines/693849 > * craft windows time ran out, did it try to compile the whole world? > > > okular - NEW > * https://invent.kde.org/graphics/okular/-/pipelines/693860 > * craft windows failed, possibly in codesign? The Windows job timed out while publishing the build artifacts. I think the problem is that all of Qt 6.7.1 was built (because the version was just bumped and the caches are not yet updated) and that just took to long in sum: *** Craft all succeeded: libs/qt6/qtbase after 10min 49s *** *** Craft all succeeded: libs/qt6/qtdeclarative after 13min 4s *** It's ironic that Hannah wrote in the Craft chat as comment on the bump to Qt 6.7.1: "this should be fine even if it will disrupt master for a couple of h" I immediately thought: "I hope that Albert doesn't starts the CI builds now." :-) The poor mac builder is probably dying because it has to compile Qt over and over again. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (master) (7 May 2024)
On Mittwoch, 8. Mai 2024 00:03:34 CEST Albert Astals Cid wrote: > dolphin - NEW > * https://invent.kde.org/system/dolphin/-/pipelines/682230 > * craft_windows_qt6_x86_64 fails without any discernible error > > > kdeconnect-kde - NEW > * https://invent.kde.org/network/kdeconnect-kde/-/pipelines/682282 > * craft_windows_qt6_x86_64 fails without any discernible error In both cases the last line logged under 'Executing "step_script" stage of the job script' is ``` Signing with custom command ``` and the error is ``` ERROR: Job failed: script timeout context: context deadline exceeded ``` This means both jobs timed out while waiting for the signer. The usual reason for the timeout is that unfortunately the windows signer stopped working once more. Maybe because the VM rebooted. Improving this is on Ben's long to do list. Re-runs of both jobs have now succeeded (after I restarted the signing service). Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Cannot change language
On Montag, 29. April 2024 14:45:17 CEST Jasem Mutlaq wrote: > With the release of KStars 3.7.0 a few weeks ago, users are no longer able > to switch languages. Once they restart the program, the language remains > the system language and cannot be changed. This is new behavior and users > complained about it. > > KStars v3.7.0 is built with KDE Frameworks 5.115.0 and Qt 5.15.13. > > Is this a bug or regression? If it worked in previous releases then it looks like a regression. It would help if you told us on which OSes the problem occurs and/or with which installers or packages (e.g. Flatpak). Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (release/24.05) (23 April 2024)
On Dienstag, 23. April 2024 18:38:35 CEST Albert Astals Cid wrote: > neochat - NEW > * https://invent.kde.org/network/neochat/-/pipelines/671682 > * craft_appimage_qt6_x86_64 and flatpak fail Apparently, https://gitlab.matrix.org/ was temporarily unavailable. Same for master. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (release/24.05) (23 April 2024)
On Dienstag, 23. April 2024 22:29:53 CEST Ingo Klöcker wrote: > On Dienstag, 23. April 2024 18:38:35 CEST Albert Astals Cid wrote: > > libkleo - NEW > > > > * https://invent.kde.org/pim/libkleo/-/pipelines/671605 > > > > * suse_tumbleweed_qt67 tests fail > > Caused by a regression in Qt 6.7.0: > https://bugreports.qt.io/browse/QTBUG-124653 Apparently, it's an intentional behavior change. *sigh* Adjust libkleo's unit test to the behavior change: https://invent.kde.org/pim/libkleo/-/merge_requests/98 Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (release/24.05) (23 April 2024)
On Dienstag, 23. April 2024 18:38:35 CEST Albert Astals Cid wrote: > libkleo - NEW > * https://invent.kde.org/pim/libkleo/-/pipelines/671605 > * suse_tumbleweed_qt67 tests fail Caused by a regression in Qt 6.7.0: https://bugreports.qt.io/browse/QTBUG-124653 Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (master) (16 April 2024)
On Dienstag, 16. April 2024 23:27:36 CEST Albert Astals Cid wrote: > kontrast - NEW > * https://invent.kde.org/accessibility/kontrast/-/pipelines/664432 > * craft android builds fail because kirigami-addons is asking for KF 6.2 More precisely, it fails because kirigami-addons now asks for kconfig but this dependency had not been added to the blueprint. (FIXED) Another problem is that kontrast master's .craft.ini asks for master of everything which is most likely unnecessary and not recommended. > keysmith - NEW > * https://invent.kde.org/utilities/keysmith/-/pipelines/664439 > * craft android builds fail because kirigami-addons is asking for KF 6.2 Same as for kontrast. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (master) (9 April 2024)
On Mittwoch, 10. April 2024 14:54:26 CEST Friedrich W. H. Kossebau wrote: > Am Mittwoch, 10. April 2024, 14:29:37 CEST schrieb Ingo Klöcker: > > On Mittwoch, 10. April 2024 13:33:46 CEST Friedrich W. H. Kossebau wrote: > > > Am Mittwoch, 10. April 2024, 13:04:47 CEST schrieb Ingo Klöcker: > > > > On Mittwoch, 10. April 2024 09:21:34 CEST Ben Cooksley wrote: > > > > > On Wed, Apr 10, 2024 at 9:51 AM Ingo Klöcker wrote: > > > > > > On Dienstag, 9. April 2024 23:26:32 CEST Albert Astals Cid wrote: > > > > > > > ktrip - NEW > > > > > > > > > > > > > > * https://invent.kde.org/utilities/ktrip/-/pipelines/657661 > > > > > > > > > > > > > > * craft_android builds fail > > > > > > > > > > > > *sigh* Why does kirigami master depend on the not yet released ECM > > > > > > 6.1.0? > > > > > > > > > > Likely as Kirigami itself is a Framework - that being said, it seems > > > > > a > > > > > bit > > > > > weird for the version bumps to be pushed to Frameworks before the > > > > > release > > > > > has been made public (because Craft cannot use them until they're > > > > > public...) > > > > > > > > I learned that this is the usual procedure for Frameworks. But it > > > > highlights why it's a bad idea for applications to depend on the > > > > master > > > > versions of Frameworks. > > > > > > In (software) development it seems usually fine to have development > > > branches of separate components depend on each other's latest state. > > > They > > > call it Continuous Integration. One of the purposes is to get > > > early-as-possible feedback, not only post-release when certain things > > > can > > > no longer be changed. In the case of KF libraries that would be e.g. > > > feasibility of new API as well as the state of the implementation. Which > > > is usually considered a good idea, both for the libraries as well as the > > > applications as the consumers of the libraries. > > > > > > It is a bad idea only from the POV of Craft users, as the tool seems not > > > yet capable to deal with development branches of all dependencies? > > > > It does support this but it will kill our CI/CD system if every Craft CD > > job builds all Frameworks from scratch. In any case, what you talk about > > is covered by the CI (Continuous Integration!) jobs. > > > > The Craft CD (Continuous Delivery/Deployment) jobs are meant to be used > > for > > building releases. When we stop doing fixed point releases and start doing > > continuous releases of Frameworks then we can talk about doing CD from > > master. > > Hm, not sure if we talk along the same lines. Let's summarize what I saw > here: > > 1. craft-tool based job on master branch of app fails > 2. reason: master branch of app expects master branch of library, job though > only supplies released version of that library I'd say this statement is wrong, but that depends on what you mean by "expects". The master branch of KTrip doesn't require (as in CMake's find_package()) the master branch of Kirigami. And the job did actually (try to) supply the master branch of Kirigami. But that failed because the master branch of Kirigami requires ECM 6.1 which the job didn't supply. > 3. claim: "highlights why it's a bad idea for applications to depend on the > master versions of Frameworks" Because one cannot use the master versions of a few selected Frameworks for a build. One needs to use the master versions of all of Frameworks. And that's expensive. > 4. "Craft CD jobs are meant to be used for building releases" > > So why are there Craft CD jobs on master branches of apps? Some apps do actually do Continuous Delivery, e.g. Itinerary. But that's only possible because Itinerary doesn't depend on unreleased Frameworks. (Well, it would be possible otherwise but it would cost/waste much more CI/CD resources.) Some projects want users to be able to check out the bleeding edge AppImage or Flatpak of their app. Same for Windows builds. This is certainly useful for example to check if bugs in some release still occur in the development version. The problem isn't "Craft CD jobs on master branches of apps". The problem is "Craft CD jobs on master branches of apps" which require unreleased Frameworks. > Or what kind of Craft jobs are those? All of them. > My point is: it is not a bad idea for applications to depend on master > versions of Frameworks, for the reasons given in my response. I agree that it's not a bad idea in general if the devs of the app have good reasons to do so. They have to take into account that long running CD jobs waste energy and the time of people waiting for the jobs to finish. In general, it's better to avoid depending on unreleased Frameworks. I would likely not contribute to a project which forces me to build Frameworks myself. I'm a happy user of the KF development packages provided by Tumbleweed. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (master) (9 April 2024)
On Mittwoch, 10. April 2024 13:33:46 CEST Friedrich W. H. Kossebau wrote: > Am Mittwoch, 10. April 2024, 13:04:47 CEST schrieb Ingo Klöcker: > > On Mittwoch, 10. April 2024 09:21:34 CEST Ben Cooksley wrote: > > > On Wed, Apr 10, 2024 at 9:51 AM Ingo Klöcker wrote: > > > > On Dienstag, 9. April 2024 23:26:32 CEST Albert Astals Cid wrote: > > > > > ktrip - NEW > > > > > > > > > > * https://invent.kde.org/utilities/ktrip/-/pipelines/657661 > > > > > > > > > > * craft_android builds fail > > > > > > > > *sigh* Why does kirigami master depend on the not yet released ECM > > > > 6.1.0? > > > > > > Likely as Kirigami itself is a Framework - that being said, it seems a > > > bit > > > weird for the version bumps to be pushed to Frameworks before the > > > release > > > has been made public (because Craft cannot use them until they're > > > public...) > > > > I learned that this is the usual procedure for Frameworks. But it > > highlights why it's a bad idea for applications to depend on the master > > versions of Frameworks. > > In (software) development it seems usually fine to have development branches > of separate components depend on each other's latest state. They call it > Continuous Integration. One of the purposes is to get early-as-possible > feedback, not only post-release when certain things can no longer be > changed. In the case of KF libraries that would be e.g. feasibility of new > API as well as the state of the implementation. Which is usually considered > a good idea, both for the libraries as well as the applications as the > consumers of the libraries. > > It is a bad idea only from the POV of Craft users, as the tool seems not yet > capable to deal with development branches of all dependencies? It does support this but it will kill our CI/CD system if every Craft CD job builds all Frameworks from scratch. In any case, what you talk about is covered by the CI (Continuous Integration!) jobs. The Craft CD (Continuous Delivery/Deployment) jobs are meant to be used for building releases. When we stop doing fixed point releases and start doing continuous releases of Frameworks then we can talk about doing CD from master. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (master) (9 April 2024)
On Mittwoch, 10. April 2024 09:21:34 CEST Ben Cooksley wrote: > On Wed, Apr 10, 2024 at 9:51 AM Ingo Klöcker wrote: > > On Dienstag, 9. April 2024 23:26:32 CEST Albert Astals Cid wrote: > > > ktrip - NEW > > > > > > * https://invent.kde.org/utilities/ktrip/-/pipelines/657661 > > > > > > * craft_android builds fail > > > > *sigh* Why does kirigami master depend on the not yet released ECM 6.1.0? > > Likely as Kirigami itself is a Framework - that being said, it seems a bit > weird for the version bumps to be pushed to Frameworks before the release > has been made public (because Craft cannot use them until they're public...) I learned that this is the usual procedure for Frameworks. But it highlights why it's a bad idea for applications to depend on the master versions of Frameworks. > The real question I have though is why does KTrip depend on Frameworks > master instead of released Frameworks? > Depending on Frameworks master is something applications should avoid > unless it is absolutely necessary. Exactly. ktrip needs a fix that's not in KF 6.0. Instead of adding a patch to Craft I told Craft to use Kirigami master. I shouldn't have done this. Lesson learned. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (master) (9 April 2024)
On Dienstag, 9. April 2024 23:26:32 CEST Albert Astals Cid wrote: > ktrip - NEW > * https://invent.kde.org/utilities/ktrip/-/pipelines/657661 > * craft_android builds fail *sigh* Why does kirigami master depend on the not yet released ECM 6.1.0? Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (release/24.02) (2 April 2024)
On Dienstag, 9. April 2024 23:33:33 CEST Albert Astals Cid wrote: > ktrip - NEW > * https://invent.kde.org/utilities/ktrip/-/pipelines/657677 > * craft builds fail I'll take care of this. I added a dependency on kirigami master because of a fix that wasn't in the KF 6.0.0 release. I should have added a patch to the Craft blueprint instead. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Should we stop distributing source tarballs?
On Freitag, 5. April 2024 12:04:28 CEST Albert Vaca Cintora wrote: > It seems a lot of people feel conservative in favor of tarballs, so > maybe I aimed too far. At least I think the discussion brought some > interesting points that we can explore further. Some I identified: > > - The tarballs should contain no changes with respect to git, or > minimal changes obviously justifiable in a diff. > - Tarballs should only be generated in a reproducible manner using > scripts. Ideally by the CI only. > - We should start to sign tarballs in the CI. We could easily add a new service for signing and publishing the tarballs to our CI/CD system. The necessary basic infrastructure has been added in the last few months as part of our migration from Binary Factory to GitLab. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (master) (27 March 2024)
On Mittwoch, 27. März 2024 23:33:52 CET Albert Astals Cid wrote: > kleopatra - NEW > * https://invent.kde.org/pim/kleopatra/-/pipelines/645399 > * flatpak fails >* It wants an unreleased version of KPim6Mime but the flatpak manifest > says it should work with release/24.02 one of the two needs fixing Already fixed by Tobias: https://invent.kde.org/pim/kleopatra/-/merge_requests/162 Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: AppStream Metadata with our releases
On Montag, 25. März 2024 23:23:01 CET Albert Astals Cid wrote: > El dissabte, 23 de març de 2024, a les 21:06:46 (CET), Julius Künzel va > escriure: > > 22.03.2024 17:22:33 Albert Astals Cid : > > > El divendres, 22 de març de 2024, a les 0:37:00 (CET), Julius Künzel va > > > escriure: > > >> - Also it would be convenient to add noteworthy changes to the metadata > > >> together with the related code change. However at the moment for KDE > > >> Gear > > >> the release is usually only added to the metadata a few days before > > >> tagging. Would it be possible to add the next minor release to the > > >> release > > >> branch right after the current one has been released and the next major > > >> release to master ones the upcoming version has been branched? > > >> > > >> I belive this makes it easier for developers to contribute to the > > >> release > > >> meta info and I hope it hence raises motivation to do so. > > > > > > My pessimistic opinion is that no one is going to add release notes, > > > we've > > > tried multiple ways to do it, even just asking people to add a keyword > > > to > > > the commit log if that commit log was release news worthy and no one did > > > it past the first few weeks/months. > > > > Well, that might happen, but we don't know if we don't try... And as I > > don't see this causing any extra work and (yet) can't see any downsides, > > it is even worth it if it helps just a single app or developer, no? > > It is some extra work (not a lot, but some). > > You're asking for the workflow of creating to be releases to be changed by > creating the entry in the file earlier, that alone is a bit of work, but it > has several other consequences: > > * https://apps.kde.org/okular/ shows releases from the appstream file (i > think) meaning that the code should learn to ignore releases in the future. > Arguably we would need also now, but given the data is added just a few days > before the actual release i think users can understand "this release will > happen soon)" compared to a thing one month in the future It's not only apps.kde.org. The release (notes) information is also used by the scripts preparing meta data for publication in various app stores. The Microsoft Store script uses the description of the most recent release found in the AppStream data for the What's New section. OTOH, the script uses the JSONified AppStream data published by apps.kde.org, so that omitting future releases in the JSONified AppStream data would also work for Microsoft Store publications. I'm not sure how the other stores use the release notes. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Markdown Tools - Request for a Sponsor
On Freitag, 15. März 2024 12:16:30 CET Igor Mironchik wrote: > https://invent.kde.org/imironchik/markdown-tools/-/issues/1 > > This is a set of applications to work with Markdown, including editor, HTML > preview viewer, converter to PDF. Do you know https://apps.kde.org/ghostwriter/? Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (master) (12 March 2024)
On Mittwoch, 13. März 2024 08:39:11 CET Ingo Klöcker wrote: > On Mittwoch, 13. März 2024 00:12:17 CET Albert Astals Cid wrote: > > Please work on fixing them, otherwise i will remove the failing CI jobs on > > their 4th failing week, it is very important that CI is passing for > > multiple reasons. > > > > Good news: 6 repositories got fixed > > > > Bad news: 2 repository still failing and 7 new repositories failing this > > week > > > > > > filelight - 2nd week > > > > * https://invent.kde.org/utilities/filelight/-/pipelines/628855 > > > > * craft fails > > One of the two macOS builds fails. No idea what the problem is because > "Job's log exceeded limit of 4194304 bytes. Job execution will continue but > no more output will be collected." I reran the job and it passed now. I saw that Justin has added an explicit list of executables to include to the Craft blueprint. No idea if this helped. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (master) (12 March 2024)
On Mittwoch, 13. März 2024 00:12:17 CET Albert Astals Cid wrote:
> Please work on fixing them, otherwise i will remove the failing CI jobs on
> their 4th failing week, it is very important that CI is passing for multiple
> reasons.
>
> Good news: 6 repositories got fixed
>
> Bad news: 2 repository still failing and 7 new repositories failing this
> week
>
>
> filelight - 2nd week
> * https://invent.kde.org/utilities/filelight/-/pipelines/628855
> * craft fails
One of the two macOS builds fails. No idea what the problem is because "Job's
log exceeded limit of 4194304 bytes. Job execution will continue but no more
output will be collected."
> kig - NEW
> * https://invent.kde.org/education/kig/-/pipelines/628852
> * craft fails
Both macOS builds failed.
arm64: packaging failed, but there's not error message and no Craft logs for
the packaging.
x86-64: signing failed with
ERROR macappsigner Error: Processing task '20240312T191325-education-
kig_1647658' failed with ReadError('unexpected end of data').
reported by tarfile
I checked the tar file manually:
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
Maybe the file wasn't closed/flushed before it was uploaded?
> neochat - NEW
> * https://invent.kde.org/network/neochat/-/pipelines/628957
> * craft fails
In this case the AppImage failed:
Deploying dependencies for ELF file /builds/network/neochat/linux-64-gcc/build/
kde/applications/neochat/archive/usr/lib/libQt6WebEngineCore.so.6.6.2
ERROR: Could not find dependency: libtiff.so.5
ERROR: Failed to deploy dependencies for existing files
tiff isn't mentioned anywhere else in the log. Looks like a missing dependency
on tiff, but I don't know in which Craft blueprint.
Regards,
Ingo
signature.asc
Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (release/24.02) (5 March 2024)
On Mittwoch, 6. März 2024 01:22:09 CET Albert Astals Cid wrote: > neochat - 2nd week > * https://invent.kde.org/network/neochat/-/pipelines/622783 > * craft builds fail Hopefully fixed with https://invent.kde.org/network/neochat/-/merge_requests/1610 Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (master) (20 February 2024)
On Mittwoch, 21. Februar 2024 11:43:39 CET Ben Cooksley wrote: > On Wed, Feb 21, 2024 at 12:01 PM Albert Astals Cid wrote: > > keysmith - 1st week > > > > * https://invent.kde.org/utilities/keysmith/-/pipelines/611882 > > > > * craft android builds fail > > Looks like it depends on Qt5Compat but misses the dependency that was > previously dragged in transitively. > Will need a fix to the Craft blueprint for Keysmith. Fixed. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (release/24.02) (20 February 2024)
On Dienstag, 20. Februar 2024 22:38:49 CET Ingo Klöcker wrote: > On Dienstag, 20. Februar 2024 22:30:56 CET Albert Astals Cid wrote: > > keysmith - 1st week > > > > * https://invent.kde.org/utilities/keysmith/-/pipelines/611904 > > > > * craft android builds fail > > I think its Craft blueprint is missing a dependency to libs/qt6/qt5compat. > In a previous build this dependency was probably pulled in by another > dependency. Fixed. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (master) (20 February 2024)
On Mittwoch, 21. Februar 2024 00:01:02 CET Albert Astals Cid wrote: > kbruch - 1st week > * https://invent.kde.org/education/kbruch/-/pipelines/611867 > * craft window build fails, but i don't see any error? The job timed out because the signing service for Windows binaries died. The service is now restarted when it dies. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (release/24.02) (20 February 2024)
On Dienstag, 20. Februar 2024 22:30:56 CET Albert Astals Cid wrote: > keysmith - 1st week > * https://invent.kde.org/utilities/keysmith/-/pipelines/611904 > * craft android builds fail I think its Craft blueprint is missing a dependency to libs/qt6/qt5compat. In a previous build this dependency was probably pulled in by another dependency. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Retirement of Binary Factory
On Montag, 19. Februar 2024 01:22:32 CET Harald Sitter wrote: > On Sun, Feb 18, 2024 at 10:23 AM Ben Cooksley wrote: > > On Sun, Feb 18, 2024 at 2:58 PM Loren Burkholder wrote: > >> Just last evening, I was downloading Filelight on a Windows machine. Due > >> to the machine being rather ancient and slow, I ended up going for the > >> direct binary download instead of the Microsoft Store download. The > >> apps.kde.org page had me download from a Binary Factory link. As of > >> right now, that link is still on https://apps.kde.org/filelight/, but it > >> obviously doesn't work. I haven't checked the apps.kde.org source, but > >> it seems that perhaps those URLs are automatically generated for each > >> app, so it should be trivial to change or remove them.> > > It would appear that Filelight has not yet enabled themselves for any form > > of continuous delivery builds aside from Flatpak. See > > https://invent.kde.org/utilities/filelight/-/blob/master/.gitlab-ci.yml?r > > ef_type=heads > > > > If Filelight contributors are still interested in supporting other > > platforms those builds will need to be added. > > I'm curious, why didn't you enable stuff for the things that were > previously building on binary factory? I have added the Windows jobs to the stable release branch of filelight (and of other projects creating APPX packages). I haven't (yet?) added Windows jobs to the master branches (or the 24.02 branches) of the 95 projects that were doing Windows builds on BF. Help is appreciated. Ideally by the project maintainers because they will have to care for the builds and it would therefore be good if they knew how the new stuff is configured. And it would be good if somebody smoke-tested the Windows builds so that we don't waste CI/CD resources for builds that don't work. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (release/23.08) (6 February 2024)
On Mittwoch, 7. Februar 2024 09:50:12 CET Ingo Klöcker wrote: > On Dienstag, 6. Februar 2024 23:58:09 CET Albert Astals Cid wrote: > > Please work on fixing them, otherwise i will remove the failing CI jobs on > > their 4th failing week, it is very important that CI is passing for > > multiple reasons. > > > > Good news: 3 repositories that were failing are fixed :) > > > > Bad news: 5 repositories are still failing and 1 new repository is failing > > > > itinerary - NEW > > > > * https://invent.kde.org/pim/itinerary/-/pipelines/601311 > > > > * googleplay_apks_qt515 fails > > Will be removed with > https://invent.kde.org/pim/itinerary/-/merge_requests/279 > (and added to 24.02 with > https://invent.kde.org/pim/itinerary/-/merge_requests/280 > where it hopefully works) Double-fixed with https://invent.kde.org/sysadmin/ci-notary-service/-/merge_requests/48 and https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/420 Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (release/23.08) (6 February 2024)
On Dienstag, 6. Februar 2024 23:58:09 CET Albert Astals Cid wrote: > Please work on fixing them, otherwise i will remove the failing CI jobs on > their 4th failing week, it is very important that CI is passing for multiple > reasons. > > Good news: 3 repositories that were failing are fixed :) > > Bad news: 5 repositories are still failing and 1 new repository is failing > > itinerary - NEW > * https://invent.kde.org/pim/itinerary/-/pipelines/601311 > * googleplay_apks_qt515 fails Will be removed with https://invent.kde.org/pim/itinerary/-/merge_requests/279 (and added to 24.02 with https://invent.kde.org/pim/itinerary/-/merge_requests/280 where it hopefully works) Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (release/24.02) (30 January 2024)
On Dienstag, 30. Januar 2024 22:36:35 CET Albert Astals Cid wrote: > Please work on fixing them, otherwise i will remove the failing CI jobs on > their 4th failing week, it is very important that CI is passing for multiple > reasons. > kleopatra - NEW > * https://invent.kde.org/pim/kleopatra/-/pipelines/594268 > * Flatpak fails to compile Fixed with https://invent.kde.org/pim/kleopatra/-/commit/ 53a0c2098d879eed6839b0e923c593a3c3aa18d3 > kdeconnect-kde -NEW > * https://invent.kde.org/network/kdeconnect-kde/-/pipelines/594276 > * craft windows failed signing? Should be fixed. The APPX signing service still used outdated project settings where the 24.02 branches were not cleared for signing. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: What can we expect from our developers
On Dienstag, 30. Januar 2024 21:47:51 CET Friedrich W. H. Kossebau wrote: > I think I understand where you are coming from, that all the work on > software done here makes the more sense the more users there are. IMHO > though reaching more users of Free Software should be done in ways and for > platforms which are not giving more power to monopolists or those which > seem set to become some. Flatpak, Snap, Windows, macOS... they are all > about binaries. There is no simple way, part of the concept, to get the > sources, patch something to one's likes and then regenerate the very same > package, just as custom one. Or is there? Yes, there is. They can simply use our infrastructure for this. We are doing much more than just providing the sources. We provide the fully functional CI/ CD machinery for building custom versions (minus digital signatures which we reserve for our official release artifacts). Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Defining a developer name for our applications metadata
On Dienstag, 30. Januar 2024 18:34:46 CET Timothée Ravier wrote: > Flathub is now requiring that applications define a "developer_name" tag in > their metadata (see [1], [2]). > > What do folks think would be a good value for our application there? > > Based on the suggestion in the documentation [3], I started making PRs [4] > [5] [6] [7] for our KDE Apps with "The KDE Community" as the > "developer_name" tag. I grepped my checked out repos and most use either "KDE Community" (9) or "The KDE Community" (5). lxr.kde.org find 25 times "KDE Community" (some with additional names) and 17 times "The KDE Community". https://lxr.kde.org/search?%21v=kf5-qt5&_filestring=&_string=%5C%3Cdeveloper_name%5C%3EKDE+Community&_casesensitive=1 https://lxr.kde.org/search?%21v=kf5-qt5&_filestring=&_string=%5C%3Cdeveloper_name%5C%3EThe+KDE+Commu&_casesensitive=1 Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (release/23.08) (23 January 2024)
On Mittwoch, 24. Januar 2024 23:03:11 CET Albert Astals Cid wrote: > El dimecres, 24 de gener de 2024, a les 8:53:45 (CET), Ingo Klöcker va > escriure: > > On Dienstag, 23. Januar 2024 23:36:21 CET Albert Astals Cid wrote: > > > okular - NEW > > > > > > * https://invent.kde.org/graphics/okular/-/pipelines/589489 > > > > > > * craft android builds are failing > > > > Looks like perl-modules/xml-parser tries to link against the ARM build of > > libexpat. > > /usr/bin/ld: skipping incompatible > > /builds/graphics/okular/android-arm-clang/ lib/libexpat.so when searching > > for -lexpat > > Is perl-modules/xml-parser used by the Android build or on the host as > > build tool? > > I don't know why xml-parser is being pulled for Okular, does craft have some > sort of "why is this thing being compiled while compiling X" command? I didn't see anything obvious while looking at craft.py. Comparing the last successful build https://invent.kde.org/graphics/okular/-/jobs/1496247#L219 with the failing build https://invent.kde.org/graphics/okular/-/jobs/1535063#L218 one sees a few new dependencies: 'libs/expat', 'perl-modules/xml-parser', 'dev-utils/intltool', 'dev-utils/ yasm', 'libs/aom', 'python-modules/meson', 'libs/dav1d', 'libs/libavif' Looks like libavif is a new dependency of kimageformats and it depends on aom which needs yasm and perl. And yasm needs intltool which needs xml-parser. I think the easiest fix is to disable the libavif dependency in kimageformats for Android for now. https://invent.kde.org/packaging/craft-blueprints-kde/-/merge_requests/773 Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (master) (23 January 2024)
On Dienstag, 23. Januar 2024 22:58:46 CET Nicolas Fella wrote: > On 1/23/24 22:46, Ingo Klöcker wrote: > > On Dienstag, 23. Januar 2024 22:11:23 CET Ben Cooksley wrote: > >> On Wed, Jan 24, 2024 at 9:36 AM Albert Astals Cid wrote: > >>> krecorder - 2nd week > >>> > >>> * https://invent.kde.org/utilities/krecorder/-/pipelines/589469 > >>> > >>>* All the craft_android builds are broken > >> > >> Looks like kirigami-addons is doing something the CMake in the Android > >> image doesn't like. > >> > >> Interesting - perhaps the CMake (which is built from source I think) > >> version in the Android image needs updating? > > > > It looks like the Android Qt 6 Craft builds fail since master was switched > > to Qt 6. My guess is that this project lacks some changes that are needed > > for building Qt 6 APKs with Craft. Maybe adding a suitable .craft.ini to > > tell Craft that a newer version of kirigami-addons (and other packages) > > has to be used for master is sufficient. See neochat for a minimal > > example. I'll have a look tomorrow. > > See https://mail.kde.org/pipermail/kde-devel/2024-January/002323.html > > kirigami-addons master has a fix that the craft-supplied version lacks It's not just that. With kirigami-addons master it fails with ninja: error: unknown target 'create-apk' https://invent.kde.org/utilities/krecorder/-/jobs/1535573 I think this means that the project hasn't been ported to the Qt 6 way for building APKs. I suggest disabling the failing jobs in master and release/ 24.02 and fixing this in an MR. Volker wrote a blog explaining how to port Android projects to Qt 6. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (release/23.08) (23 January 2024)
On Dienstag, 23. Januar 2024 23:36:21 CET Albert Astals Cid wrote: > kleopatra - NEW > * https://invent.kde.org/pim/kleopatra/-/pipelines/589543 > * FAILS TO COMPILE accessiblevaluelabel in FreeBSD https://invent.kde.org/pim/kleopatra/-/merge_requests/103 > okular - NEW > * https://invent.kde.org/graphics/okular/-/pipelines/589489 > * craft android builds are failing Looks like perl-modules/xml-parser tries to link against the ARM build of libexpat. /usr/bin/ld: skipping incompatible /builds/graphics/okular/android-arm-clang/ lib/libexpat.so when searching for -lexpat Is perl-modules/xml-parser used by the Android build or on the host as build tool? Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (release/24.02) (23 January 2024)
On Dienstag, 23. Januar 2024 23:25:46 CET Albert Astals Cid wrote: > Please work on fixing them, otherwise i will remove the failing CI jobs on > their 4th failing week, it is very important that CI is passing for > multiple reasons. > > Good News: 9 failing repositories from previous report got fixed > > Bad news: 2 repositories are still failing and *9* new repositories started > failing Thanks for the summary! > kleopatra - NEW > * https://invent.kde.org/pim/kleopatra/-/pipelines/589624 > * FAILS TO COMPILE accessiblevaluelabel in FreeBSD https://invent.kde.org/pim/kleopatra/-/merge_requests/102 Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (master) (23 January 2024)
On Dienstag, 23. Januar 2024 22:11:23 CET Ben Cooksley wrote: > On Wed, Jan 24, 2024 at 9:36 AM Albert Astals Cid wrote: > > Please work on fixing them, otherwise i will remove the failing CI jobs on > > their 4th failing week, it is very important that CI is passing for > > multiple reasons. > > > > Good news: 5 repositories got fixed > > > > Bad news: 2 repo still failing (1 with a different failure) and *10* new > > this week > > > > > > krecorder - 2nd week > > > > * https://invent.kde.org/utilities/krecorder/-/pipelines/589469 > > > > * All the craft_android builds are broken > > Looks like kirigami-addons is doing something the CMake in the Android > image doesn't like. > > Interesting - perhaps the CMake (which is built from source I think) > version in the Android image needs updating? It looks like the Android Qt 6 Craft builds fail since master was switched to Qt 6. My guess is that this project lacks some changes that are needed for building Qt 6 APKs with Craft. Maybe adding a suitable .craft.ini to tell Craft that a newer version of kirigami-addons (and other packages) has to be used for master is sufficient. See neochat for a minimal example. I'll have a look tomorrow. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (master) (9 January 2024)
On Mittwoch, 10. Januar 2024 09:25:27 CET Ingo Klöcker wrote: > On Mittwoch, 10. Januar 2024 00:23:55 CET Nicolas Fella wrote: > > On 1/9/24 23:45, Albert Astals Cid wrote: > > > krecorder - NEW > > > > > > *https://invent.kde.org/utilities/krecorder/-/pipelines/577438 > > > > > >* All the craft_android builds are broken > > > > This needs > > https://invent.kde.org/libraries/kirigami-addons/-/commit/3de0aae116276a1c > > d4 ca7adb81d273225f546d80, which isn't in the version craft has > > Will hopefully be fixed with > https://invent.kde.org/utilities/krecorder/-/merge_requests/31 Now it fails for other reasons, but the Qt 6 builds seem to be work in progress. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (master) (9 January 2024)
On Mittwoch, 10. Januar 2024 00:23:55 CET Nicolas Fella wrote: > On 1/9/24 23:45, Albert Astals Cid wrote: > > krecorder - NEW > > > > *https://invent.kde.org/utilities/krecorder/-/pipelines/577438 > > > >* All the craft_android builds are broken > > This needs > https://invent.kde.org/libraries/kirigami-addons/-/commit/3de0aae116276a1cd4 > ca7adb81d273225f546d80, which isn't in the version craft has Will hopefully be fixed with https://invent.kde.org/utilities/krecorder/-/merge_requests/31 Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (master) (9 January 2024)
On Dienstag, 9. Januar 2024 23:45:03 CET Albert Astals Cid wrote: > filelight - NEW > * https://invent.kde.org/utilities/filelight/-/pipelines/577430 > * flatpak build fails, seems that > https://invent.kde.org/sysadmin/ci-utilities/-/merge_requests/210 should > have fixed it but it didn't. There's more steps involved and Ingo will take > care of them This is now fixed. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (release/23.08) (9 January 2024)
On Mittwoch, 10. Januar 2024 01:00:06 CET Albert Astals Cid wrote: > Please work on fixing them, otherwise i will remove the failing CI > jobs on their 4th failing week, it is very important that CI is passing for > multiple reasons. > > Good news: The 2 repositories that were failing are fixed :) > > Bad news: 1 new repository failing > > itinerary - NEW > * https://invent.kde.org/pim/itinerary/-/pipelines/577504 > * All craft_android builds are failing Probably related to khealthcertificate becoming Qt6-only on Monday. > P.S: This is assuming > https://invent.kde.org/network/neochat/-/pipelines/577514 > passes I got tired of waiting for it to finish In the end the pipeline failed because the Windows signing service wasn't running. This is fixed. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Kandalf: request for review
On Dienstag, 19. Dezember 2023 13:47:11 CET Alexander Neundorf wrote: > On Dienstag, 19. Dezember 2023 08:31:56 CET Ingo Klöcker wrote: > > Calling someone by any animal name is mostly offensive. It's a pretty > > stupid argument to stop calling apps after animals. You should rather > > stop calling people by animal names. > > did I call anybody a Kamel ? No, sorry. I didn't mean to imply this. I meant all people in general and should have written "We should [...]". Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Kandalf: request for review
On Montag, 18. Dezember 2023 23:30:57 CET jvap...@gmail.com wrote: > On Montag, 18. Dezember 2023 22:27:43 CET Alexander Neundorf wrote: > > A Kamel is a big, slow and un-funny animal, in german it's also not a > > compliment to call somebody a Kamel. > > I had no idea. > > Yes, if it is offensive then, do not use it. Calling someone by any animal name is mostly offensive. It's a pretty stupid argument to stop calling apps after animals. You should rather stop calling people by animal names. Moreover, I think camels are pretty cool. And so does O'Reilly (https://www.oreilly.com/library/view/programming-perl-4th/9781449321451/). Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Spacing in our apps
On Sonntag, 17. Dezember 2023 13:21:32 CET Carl Schwan wrote: > a) Remove smallSpacing and largeSpacing from Kirigami, and rename > mediumSpacing to just spacing. This unified spacing value would be defined > in qqc2-desktop-style to use whatever value is defined in the current > QStyle. > > a bis) Instead of creating only a generic "spacing" property, we create a > "Kirigami.Units.margins" or "Kirigami.Units.paddings" property to use for > paddings of QtQuick Controls and mapped to the Layout*Margin pixel metrics > and a "Kirigami.Units.spacing" property mapped to the Layout*Spacing pixel > metrics. For Breeze and Oxygen, both value would map to 6 pixels anyway, > but it might make it easier to switch to other values in the future as well > as make the usage of Units value more explit. +1 for getting rid of choices because it makes my life easier if I don't have to think about which value is the correct one in some situation. I don't have an opinion on a bis), but I guess it makes sense to mirror the QWidget pixel metrics in QML. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Kandalf: request for review
On Dienstag, 12. Dezember 2023 06:23:07 CET Ömer Fadıl USTA wrote: > On Tue, Dec 12, 2023, 07:40 Loren Burkholder wrote: > > Hi all, > > > > I've settled on "Kognos" as a good name for this app. (I'm not creative > > enough to come up with the name myself; fittingly, this name was generated > > by ChatGPT.) Only after I had already changed the sources to say "Kognos" > > instead of "Kandalf" did I think to look the name up online; it seems that > > there was a company called Kognos, but they were bought out and the name > > was retired a year or two ago, so I don't think that we're in danger of a > > naming collision. Furthermore, the US Patent and Trademark Office doesn't > > have Kognos listed as a registered trademark. With that being said, I'm > > all > > for staying within the law, so if you have legitimate reason to think that > > Kognos is not acceptable, let me know. > > isnt cognos ( not k but c ) IBM's software ? Indeed. IBM Cognos Analytics (https://www.ibm.com/products/cognos-analytics). Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear 24.02 feature freeze and branching
On Samstag, 25. November 2023 00:30:05 CET Albert Astals Cid wrote: > According to https://community.kde.org/Schedules/February_2024_MegaRelease > feature freeze is 29 November (i.e. next week). > > Due to this release being a bit special we will create the branches a bit > later, a few days before RC1 (10 January 2024). > > This means that between 29 November and branching time, master in KDE Gear > repositories is bugfix only (Qt6 porting is allowed). I'm wondering how to deal with merges to master from kf5-based branches where feature development will continue. Specifically, I'm talking about libkleo, kleopatra, mimetreeparser and probably a few other (PIM) projects. Feature development (and bug fixing) continues in the kf5 branches for Gpg4Win and related releases done by g10Code. I suppose the easiest solution would be to postpone any merges from kf5 to master until KDE Gear is branched. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (master) (22 November 2023)
On Donnerstag, 23. November 2023 17:00:13 CET Volker Krause wrote: > On Donnerstag, 23. November 2023 12:04:24 CET Ingo Klöcker wrote: > > On Donnerstag, 23. November 2023 00:09:48 CET Albert Astals Cid wrote: > > > == kuserfeedback woes == > > > > > > kate > > > > > > * https://invent.kde.org/utilities/kate/-/pipelines/538985 > > > > > > dolphin > > > > > > * https://invent.kde.org/system/dolphin/-/pipelines/538986 > > > > > > kuserfeedback isn't available for Windows in the registry. Looking at > > > it, > > > it hasn't compiled for days, what's going on there? > > > > Windows CI has recently been switched to Qt 6.6. If kuserfeedback master > > wasn't built since then then it's obvious why no Qt 6.6 build is available > > in the registry. Our CI doesn't magically rebuilt all projects if we > > update > > the CI images. Could this be fixed? Probably. > > That's what the seed jobs are for, Ah. So for most of us the rebuild happens seemingly automagically provide the magicians or their apprentices hit the Run Seed Job buttons. :-) Thanks magicians and apprentices for taking care of this! Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (master) (22 November 2023)
On Donnerstag, 23. November 2023 00:09:48 CET Albert Astals Cid wrote: > == kuserfeedback woes == > > kate > * https://invent.kde.org/utilities/kate/-/pipelines/538985 > > dolphin > * https://invent.kde.org/system/dolphin/-/pipelines/538986 > > kuserfeedback isn't available for Windows in the registry. Looking at it, it > hasn't compiled for days, what's going on there? Windows CI has recently been switched to Qt 6.6. If kuserfeedback master wasn't built since then then it's obvious why no Qt 6.6 build is available in the registry. Our CI doesn't magically rebuilt all projects if we update the CI images. Could this be fixed? Probably. I have now triggered a pipeline for kuserfeedback master (which has already completed successfully). Let's see whether this fixes the problem. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: CI log verbosity
On Freitag, 3. November 2023 13:01:26 CET Harald Sitter wrote: > What are your thoughts on having the CI be less verbose by default and > instead have an env var or some other toggle to switch into verbose > mode? +1 Ideally, the verbose logs would be written to an artifact. Otherwise, it will be painful to debug intermittent problems. I think the Craft jobs now do this (also in response to insanely verbose output of some builds which made it impossible to see the actual error). > Specifically I'm talking about the qtlogging rules that are currently > enabling everything and the kitchen sink. To my mind we should just > use the default rules by default. > I find that 99% of the time the output is entirely useless in finding > what is wrong, if anything it gets in the way because I first have to > find where the test failure is and then instead of reading walls of qt > plugin info I will just proceed to reproduce the problem locally > anyway. Full ACK. I'm almost always only interested in finding the error which caused the CI job to fail and sometimes in seeing compiler warnings. Regards, Ingo signature.asc Description: This is a digitally signed message part.
The modern way to include our CI templates in your .gitlab-ci.yml
Hi everybody, TL,DR: Use include:project when including CI templates in your .gitlab-ci.yml, e.g. ``` include: - project: sysadmin/ci-utilities file: - /gitlab-templates/linux-qt6.yml - /gitlab-templates/freebsd-qt6.yml - /gitlab-templates/android-qt6.yml - /gitlab-templates/reuse-lint.yml - /gitlab-templates/flatpak.yml ``` Details Some of our CI templates are making use of local includes (think a KDE Frameworks header that includes another header from the same framework with #include "other.h"). Unfortunately, local includes are incompatible with our old way to include the CI templates, i.e. ``` include: - https://invent.kde.org/sysadmin/ci-utilities/raw/master/gitlab-templates/ linux-qt6.yml ``` If you try this with the (still experimental) craft-android-apks.yml template, then GitLab will be very unhappy and tell you | Unable to create pipeline | | * Local file `gitlab-templates/craft-android-base.yml` does not have project! Therefore, we have to switch to the "modern" include:project [1]. This format also offers an intuitive way to include CI templates from a work branch if you are hacking on the CI templates and want to test them by adding a `ref`, e.g. ``` include: [...] - project: sysadmin/ci-utilities ref: work/kloecker/improve-craft-templates file: - /gitlab-templates/craft-android-apks.yml ``` More information about our CI system can be found at https://community.kde.org/Infrastructure/Continuous_Integration_System And a brief description of our CI/CD templates can be found at https://invent.kde.org/sysadmin/ci-utilities/-/tree/master/gitlab-templates#our-gitlab-cicd-pipelines Regards, Ingo [1] https://invent.kde.org/help/ci/yaml/index.md#includeproject signature.asc Description: This is a digitally signed message part.
Re: Problems when adding a combo box to a toolbar and KActionCollection in KF6
On Montag, 30. Oktober 2023 09:53:08 CET Stefano Crocco wrote: > On lunedì 30 ottobre 2023 01:11:27 CET Nicolas Fella wrote: > > On 10/29/23 18:38, Stefano Crocco wrote: > > > Hello to everyone, > > > while porting Konqueror to KF6, I've hit a problem I don't know how to > > > solve. The issue is that it's impossible to give focus to the location > > > bar by clicking on it with the mouse as you can do in KF5. > > > > focus and toolbar brings > > https://invent.kde.org/frameworks/kxmlgui/-/merge_requests/188 to my > > mind. Can you check whether it works as you expect before that change? > > Yes, without that change, everything works correctly. Thanks for the > information. > > Do you think it would make sense to create a merge request for kxmlgui so > that the focus policy is only changed if it doesn't include TabFocus? Yes, if the current policy flags don't include TabFocus then TabFocus should be added but the current policy flags should be kept. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Review: Hash-o-Matic
On Sonntag, 1. Oktober 2023 21:49:36 CEST Carl Schwan wrote: > It would be great if someone could create a product on bugs.kde.org and > assign myself to the product. Are you sure you cannot create the product yourself? https://bugs.kde.org/editproducts.cgi Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: libicu dependancy
On Sonntag, 17. September 2023 20:59:12 CEST Michael Reeves wrote: > Is libicu in the CI images already? Yes, look at the output of a job that builds a CI image to see what's installed in the image: https://invent.kde.org/sysadmin/ci-images/-/jobs Click Finished to hide jobs that didn't run. For example https://invent.kde.org/sysadmin/ci-images/-/jobs/1193867 shows that libicu-devel is installed in the suse-qt65 image. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: How to get dependencies into freebsd ci?
On Samstag, 16. September 2023 22:46:43 CEST Ben Cooksley wrote: > On Sun, Sep 17, 2023 at 8:37 AM Ingo Klöcker wrote: > > On Samstag, 16. September 2023 22:08:46 CEST Milian Wolff wrote: > > > And cppcheck is nice, but it's a long shot from clang-tidy and clazy. I > > > understand that's the way it is for now and it's not possible to get > > > additional checks enabled for projects? > > > > I'm not sure what you mean by "not possible to get additional checks > > enabled > > for projects", but okular has a custom job which runs clang-tidy and > > clazy. > > This job does a few things which are very specific for okular. I've just > > started to set up a similar job for libkleo: > > https://invent.kde.org/pim/libkleo/-/merge_requests/45 > > Where possible do try to avoid too many custom jobs - especially where they > duplicate functions like we're seeing here. > In the case of both Okular and libkleo here i'm seeing that they install > stuff from distribution repos - which can result in unpredictable failures > due to network issues. The idea is to make a standard job out of this once it's clear how this would look like. I think other people were interested in running clazy (and maybe clang-tidy) for their projects. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: How to get dependencies into freebsd ci?
On Samstag, 16. September 2023 22:08:46 CEST Milian Wolff wrote: > And cppcheck is nice, but it's a long shot from clang-tidy and clazy. I > understand that's the way it is for now and it's not possible to get > additional checks enabled for projects? I'm not sure what you mean by "not possible to get additional checks enabled for projects", but okular has a custom job which runs clang-tidy and clazy. This job does a few things which are very specific for okular. I've just started to set up a similar job for libkleo: https://invent.kde.org/pim/libkleo/-/merge_requests/45 Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Merging a 2nd style (non xml) for KConfigXT?
On Mittwoch, 30. August 2023 11:43:27 CEST Tomaz Canabrava wrote:
> Things that KConfigXT XML lacks:
>
> * Access to the default value of a setting (KConfigXT allows me to
> define one, but I can't use it on a if in the codebase, there's no way
> to query it back)
There's no nice entryNameDefault() API, but you can get the default value. At
least, a static one:
```
Settings{}.findItem(QStringLiteral("RetrieveSignerKeysAfterImport"))-
>getDefault().toBool()
```
> * Compartimentalized acessors: bgColor() exists inside of the Gui class,
> not on SomePreferences, so it's easier to organize.
Yeah, it's really a pity that the groups one puts the entries in in the XML
are not exposed in the API.
Regards,
Ingo
signature.asc
Description: This is a digitally signed message part.
Re: [announcement] Telegram bridging to be retired Wed. 20 Sept. | 5 to-dos
On Mittwoch, 23. August 2023 09:34:04 CEST Tomaz Canabrava wrote: > (On top of what Paul said, if this happens, should we also stop with the > Reddit and Facebook management, since it’s a closed source software on for > profit companies?) The Telegram bridging is shut down because of unmanageable technical problems and not for political reasons. If it ran smoothly, then I don't think it would be shut down. Don't read more into this than there is. In particular, this isn't a conspiracy against Telegram users. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Strange language setting issues
On Mittwoch, 22. März 2023 21:38:58 CET Michael Reeves wrote: > I receiving complaints about French words appearing sporadically on > KDiff3's GUi even when KDiff3 itself is set to use English. > I strongly suspect a setup issue within Windows but require assistance to > rule out frameworks/qt involvement in the issue. > https://bugs.kde.org/show_bug.cgi?id=442607 > > KDiff3 itself does not attempt to interfere with or alter the translation > process in any way, As Albert already commented on the bug report this should have been fixed with https://invent.kde.org/frameworks/ki18n/-/merge_requests/78 and a similar MR for ECM. The latest Windows installers of KDiff3 do already use KF 5.104 which contains the MRs. Since this was a general problem in the way the application specific language was set in KF affecting Windows and, according to the code of QLocale, most likely also macOS, all bug reports reporting translation issues (mix of system language with configured application language) on Windows/macOS should be rechecked. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Forks cleanup
On Sonntag, 19. März 2023 04:30:09 CET Ben Cooksley wrote: > Hi all, > > While doing some routine maintenance and system assessments on our Gitlab > instance over the past week, it has become apparent that in certain > circumstances the de-duplication of objects between parent repositories and > their forks does not work correctly in some circumstances. > > While this isn't a significant issue as the system is well oversized to > handle growth, it is causing backups to take longer than they should to run > and makes certain estimates of future resource needs difficult to determine. > > It would therefore be appreciated if people could please remove any forks > they are no longer using. The button to remove a fork is hidden deep in the General project Settings under the subsection Advanced. See https://stackoverflow.com/a/59153938 for screenshots. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Forks cleanup
On Sonntag, 19. März 2023 04:30:09 CET Ben Cooksley wrote: > Hi all, > > While doing some routine maintenance and system assessments on our Gitlab > instance over the past week, it has become apparent that in certain > circumstances the de-duplication of objects between parent repositories and > their forks does not work correctly in some circumstances. > > While this isn't a significant issue as the system is well oversized to > handle growth, it is causing backups to take longer than they should to run > and makes certain estimates of future resource needs difficult to determine. > > It would therefore be appreciated if people could please remove any forks > they are no longer using. The button to remove a fork is hidden deep in the General project Settings under the subsection Advanced. See https://stackoverflow.com/a/59153938 for screenshots. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Usage of KF5/KF6 in targets and CMake config files outside of Frameworks
On Donnerstag, 9. März 2023 16:58:40 CET Heiko Becker wrote: > while looking at a MR for libkcddb (part of Gear) I wondered if the > transition > from Qt5/KF5 to Qt6/KF6 could be used to get rid of the KF5/6 prefix in > target > names and CMake config files for libraries that aren't acutally part of > Frameworks. +1 > Changing that obviously involves some (temporary) compatibility concerns, > but that doesn't play any role with the move to Qt6/KF6. So I suggest to > use the chance and get rid of said prefix with the upcoming porting. > > One example where this was done already some time ago is libkgapi: > https://invent.kde.org/pim/libkgapi/-/commit/8d15e66f1ed87a52377111735e24888 > b7f924a49 This is a particular bad example because it changes the name of the Qt5 version breaking all existing Qt5-based users instead of just fixing the name for Qt6/KF6. (Yes, this KDE PIM library isn't public API, so it doesn't hurt external users. But it has cost me many hours compiling libraries from source where I previously could always use the distribution packages). Please don't follow this annoying example. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Usage of KF5/KF6 in targets and CMake config files outside of Frameworks
On Donnerstag, 9. März 2023 16:58:40 CET Heiko Becker wrote: > while looking at a MR for libkcddb (part of Gear) I wondered if the > transition > from Qt5/KF5 to Qt6/KF6 could be used to get rid of the KF5/6 prefix in > target > names and CMake config files for libraries that aren't acutally part of > Frameworks. +1 > Changing that obviously involves some (temporary) compatibility concerns, > but that doesn't play any role with the move to Qt6/KF6. So I suggest to > use the chance and get rid of said prefix with the upcoming porting. > > One example where this was done already some time ago is libkgapi: > https://invent.kde.org/pim/libkgapi/-/commit/8d15e66f1ed87a52377111735e24888 > b7f924a49 This is a particular bad example because it changes the name of the Qt5 version breaking all existing Qt5-based users instead of just fixing the name for Qt6/KF6. (Yes, this KDE PIM library isn't public API, so it doesn't hurt external users. But it has cost me many hours compiling libraries from source where I previously could always use the distribution packages). Please don't follow this annoying example. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: PSA: Mark SVG as binary
On Freitag, 3. März 2023 22:49:06 CET Ben Cooksley wrote: > In all cases i'm aware of, the files have been in either SVG, JSON or XML > in format. > > To fix this, and allow changes to be merged please add a ".gitattributes" > file at the top level of the Git repository you are seeing this behaviour > in on the master branch with the following contents: > > *.svg binary Wouldn't replacing the *.svg files with compressed SVGs also solve the problem? If git is anyway told to treat the SVGs as binary, then keeping them as uncompressed text files makes little sense to me. Of course, there may be valid exceptions, but I'm certain that in general replacing the uncompressed SVGs with compressed SVGs would be fine. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: PSA: Mark SVG as binary
On Freitag, 3. März 2023 22:49:06 CET Ben Cooksley wrote: > In all cases i'm aware of, the files have been in either SVG, JSON or XML > in format. > > To fix this, and allow changes to be merged please add a ".gitattributes" > file at the top level of the Git repository you are seeing this behaviour > in on the master branch with the following contents: > > *.svg binary Wouldn't replacing the *.svg files with compressed SVGs also solve the problem? If git is anyway told to treat the SVGs as binary, then keeping them as uncompressed text files makes little sense to me. Of course, there may be valid exceptions, but I'm certain that in general replacing the uncompressed SVGs with compressed SVGs would be fine. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: New santizer warning in KF 5.98 headers
On Mittwoch, 11. Januar 2023 11:02:04 CET Milian Wolff wrote: > On Dienstag, 10. Januar 2023 23:45:26 CET Michael Reeves wrote: > > Thanks. I would say your right there this would definitely have caught > > someone's attention if didn't work in practice with what kde needs. > > Santizers are by design quite pedantic as serves there purpose well. > > I agree, the code is clearly wrong and it's unclear what it's trying to > achieve here. Does anyone know what this is trying to do? > > Qt::ConnectionType connectionType = static_cast(-1) > > Should this maybe just be changed to use Qt::AutoConnection? The code: https://invent.kde.org/frameworks/kconfigwidgets/-/blob/master/src/ kstandardaction.h#L253 What the code does: The default value `static_cast(-1)` serves as hint that the function should decide what kind of connection type to use and for some reason the `ConfigureToolbars` action explicitly needs to use a `Qt::QueuedConnection` instead of a `Qt::AutoConnection`. This could be changed to a std::optional (for KF6) to make the intention clear. Why the code does what it does: One could question whether this special casing for `ConfigureToolbars` is still necessary. The bug report about the crash that this seems to have fixed is from 2009: https://bugs.kde.org/show_bug.cgi?id=200815 Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: New repo in kdereview: KWeather
On Montag, 28. November 2022 17:53:59 CET Devin wrote: > > FWIW i can't open settings anymore > > Make sure you have the latest kirigami-addons built (from master). I have read "use the latest kirigami-addons" many times in the last few weeks. Isn't it possible to add a version check to detect this and show an appropriate error if users of kirigami-addons don't use the required version? Whenever I add new API to libkleo that I use in Kleopatra, I bump the version of libkleo and require the bumped version in Kleopatra, so that people building Kleopatra immediately notice if they need to update libkleo. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Plasma Welcome Center on KDEReview
On Dienstag, 25. Oktober 2022 22:07:35 CEST Nate Graham wrote: > On 10/25/22 02:01, Ingo Klöcker wrote: > > On Montag, 24. Oktober 2022 23:16:50 CEST Nate Graham wrote: > >> Where does that YAML file live? > > > > The whole review process including the location of the YAML file is > > described at https://community.kde.org/Policies/Application_Lifecycle . > > > > I'm wondering how you manage to pass the review process seemingly without > > knowing about this page. :-) > > I know about that page, but I haven't memorized every detail of it, or > been able to always recall it as the location for the exact piece of > information I was looking for. You asked for the location of the YAML file, so I reminded you (and everybody else) where to find the location. I apologize for my tongue-in-cheek comment. Apparently, it came across the wrong way. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Plasma Welcome Center on KDEReview
On Montag, 24. Oktober 2022 23:16:50 CEST Nate Graham wrote: > OK great, thanks! Good to notify people when doing it. :) > > Where does that YAML file live? The whole review process including the location of the YAML file is described at https://community.kde.org/Policies/Application_Lifecycle . I'm wondering how you manage to pass the review process seemingly without knowing about this page. :-) Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Windows troubleshooting help for KDiff3 Installer.
On Montag, 24. Oktober 2022 19:21:11 CEST Michael Reeves wrote: > I've got a report that the installer seems to crash on startup would like > some assistance identfiing the cause. > > https://bugs.kde.org/show_bug.cgi?id=459484 The installer was just flagged by some scanner. It's the installed application, i.e. KDiff3, that crashes on start-up. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Gitlab update, 2FA now mandatory
On Montag, 24. Oktober 2022 01:37:23 CEST Kevin Kofler wrote: > In short, the 2FA requirement is unacceptable and needs to be disabled > immediately. You are the only person in this thread (on kde-core-devel) who has voiced their disagreement with using 2FA and who demand its immediate deactivation. Why do you think a single person (you) who isn't tasked with keeping our infrastructure and the data stored thereon secure should be able to decide this? I for one applaud the requirement to use 2FA on invent. I would love to see this on more websites. And, for what it's worth, since invent keeps personal information and since the GDPR requires using state-of-the-art technology to protect personal information, using 2FA is, in my opinion (but I'm not a lawyer), a must for any website that stores personal information. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: ghostwriter is ready for your review
On Sonntag, 16. Oktober 2022 05:05:40 CEST Megan wrote: > > You have 4 libs in the 3rdparty folder, is there any chance to use actual > > dependencies and not copied code? > > 1. Unfortunately, some of the dependencies aren't in every GNU/Linux > distribution. > 2. It is easier for doing Windows and MacOS builds to have the > dependencies bundled with the app code. I don't think so. We have Craft (https://community.kde.org/Craft) for taking care of all kinds of dependencies for various platforms and for building our applications for Windows and MacOS (https://binary-factory.kde.org/). Don't reinvent the wheel! · > 3. To protect against sudden API changes across distros, it's best to > freeze the versions of the dependencies needed by keeping them bundled. > This way I can upgrade them when I'm prepared to rather than as an > emergency fix. This is also nicely handled by Craft. For Linux, it's much better to rely on the libraries provided by the distribution. Or are you prepared to handle security advisories for all of those libraries? Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Plasma Welcome Center on KDEReview
On Montag, 19. September 2022 03:01:14 CEST Nate Graham wrote: > On 9/18/22 11:44, Nicolas Fella wrote: > > - appstreamcli validate --pedantic org.kde.plasma-welcome.appdata.xml > > has some warnings: > > > > P: org.kde.plasma-welcome.desktop:12: screenshot-no-caption > > P: org.kde.plasma-welcome.desktop:~: releases-info-missing > > I: org.kde.plasma-welcome.desktop:3: cid-contains-hyphen > > org.kde.plasma-welcome.desktop > > P: org.kde.plasma-welcome.desktop:15: screenshot-no-caption > > I don't think these are real issues. There are no releases yet, the > screenshots not having captions is intentional (their content seems > totally obvious to me), Please try to keep in mind that there are people who cannot see screenshots. They may not need captions, but they do need a textual description of the screenshot. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Gitlab CI Dashboards and retirement of build.kde.org
On Samstag, 3. September 2022 21:29:17 CEST Ben Cooksley wrote: > At this time the Binary Factory is unaffected by these changes, however > steps will be made in the coming weeks/months to migrate away from the > Binary Factory to equivalent Gitlab jobs (although they won't be available > for Merge Requests due to various technical limitations) Is there some more information on this somewhere? In particular, I might be able to help with this as part of my role in the Bring KDE apps to the App Stores story. I found https://invent.kde.org/sysadmin/task-queue/-/issues/10 (binary- factory.kde.org migration to the Gitlab CI), but that hasn't been touched in the last 18 months. And neither has https://invent.kde.org/sysadmin/task-queue/-/issues/9 (build.kde.org migration to Gitlab CI) which can be closed now, I suppose. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: QCA2
On Sonntag, 11. September 2022 10:35:43 CEST Albert Astals Cid wrote: > El diumenge, 11 de setembre de 2022, a les 4:44:24 (CEST), Ron Murray va > >Since QCA invokes the gpg executable anyway, it makes more sense to > > just let gpg bring up a pinentry dialog. > > That's not QCA design, the design is that the application brings up its own > dialog if it needs it when it gets asked via the QCA::Event::Password > request. Which is completely against the design goal of gpg2 to minimize the attack surface of code that deals with sensitive information like the private key data (done exclusively by gpg-agent) and passwords (done by gpg-agent in concert with pinentry). Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: QCA2
On Samstag, 10. September 2022 05:00:26 CEST Ron Murray wrote: >I'm working on a project using Qt5, GPG and QCA2, the latter because > it can encrypt and decrypt PGP messages. This, of course, involves > using the qca-gnupg plugin. The recommended way, by the developers of GnuPG, is to use the official Qt binding QGpgME which is part of GpgME. Most users of OpenPGP developed by KDE like KMail and, of course, Kleopatra use QGpgME. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Git merge workflow: reverse it?
On Dienstag, 10. Mai 2022 11:48:30 CEST Harald Sitter wrote: > On Tue, May 10, 2022 at 10:59 AM Ingo Klöcker wrote: > > On Dienstag, 10. Mai 2022 09:36:17 CEST Kai Uwe Broulik wrote: > > > can we get an update on this? > > > > > > Plasma is full on cherry-pick now but in KDE Gear it's inconsistent and > > > frustrating when some projects use cherry-pick (e.g. Kate) and some > > > don't (e.g. Dolphin). > > > > > > I don't really mind what the outcome is but I need it to be consistent > > > and predictable where to target my MRs, at least for every domain > > > (Plasma, Gear, ..). > > > > I can imagine a consistent rule for Frameworks (if that's what you mean by > > "domain"). Apart from that I can only imagine a consistent rule per > > development team, e.g. Plasma team or PIM team, but not for Gear as a > > whole > > which is just a random mix of the products of different teams with > > different workflows. Of course, this doesn't stop the different > > development teams from adopting the same merge workflow. But this cannot > > be forced on all development teams. > > I'm sure we can, it's one of the technical pillars of the manifesto :) I wish top-posting was forbidden by the manifesto. ;-) > 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 signature.asc Description: This is a digitally signed message part.
Re: Git merge workflow: reverse it?
On Dienstag, 10. Mai 2022 09:36:17 CEST Kai Uwe Broulik wrote: > can we get an update on this? > > Plasma is full on cherry-pick now but in KDE Gear it's inconsistent and > frustrating when some projects use cherry-pick (e.g. Kate) and some > don't (e.g. Dolphin). > > I don't really mind what the outcome is but I need it to be consistent > and predictable where to target my MRs, at least for every domain > (Plasma, Gear, ..). I can imagine a consistent rule for Frameworks (if that's what you mean by "domain"). Apart from that I can only imagine a consistent rule per development team, e.g. Plasma team or PIM team, but not for Gear as a whole which is just a random mix of the products of different teams with different workflows. Of course, this doesn't stop the different development teams from adopting the same merge workflow. But this cannot be forced on all development teams. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Reviewing the process for giving people commit rights
On Samstag, 2. April 2022 11:21:11 CEST Kevin Kofler wrote: > Nate Graham wrote: > > This caused a problem recently in KWin. A new contributor was given > > commit rights very soon after he appeared, and then immediately after > > that, he inappropriately merged a not-fully-reviewed an un-accepted > > merge request > > (https://invent.kde.org/plasma/kwin/-/merge_requests/1980). It seems > > that he did not have a sense of the cultural norms around committing to > > KDE repos, and giving him commit access was probably premature. > > Well, the question this calls for is why the merge request was still not > fully reviewed almost six weeks after submission. I would guess that that is > what the misunderstanding came from: the submitter most likely assumed that > the changes were fine given that there were no outstanding comments. (The > submitter did try to address those comments that you had in those six > weeks.) > > I should also point out that the complaints in Xaver Hugl's post-merge > review were all only formatting/whitespace, choice of comment sign, and > brace issues (with no effect on the end user at all), Several PIM libraries have clang-format pre-commit hooks that prevent formatting issues in the first place (and, occasionally, annoy me because the hooks also complain about formatting issues in unstaged/uncommitted code, e.g. temporarily commented out code where the commented out code is not correctly indented). Formatting is something no reviewer should have to waste brain energy on nowadays. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Reviewing the process for giving people commit rights
On Freitag, 1. April 2022 17:52:50 CEST Ivan Čukić wrote: > On Friday, 1 April 2022 17:36:50 CEST Nicolas Fella wrote: > > To summarize: I don't see a need to change how applications are > > +1 -+1 > One of the things I saw as a mark of a welcoming and trusting community > when I joined KDE was that everyone had direct push access to trunk > (good old SVN). Exactly. I very much agree with this. I very much prefer a low entry barrier for giving new people commit rights and I see no reason to change our current process just because a single push didn't follow our agreed standard. It's not as if a large proportion of new people would cause trouble, is it? How are new people supposed to learn our ways if they are not allowed to make errors? It's not as if people could do serious damage. In case of severe problems with a committer it's easy to revoke their commit rights and shouldn't be too difficult to undo the damage they have done. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Changing Original Library API when writing Wrappers
On Sonntag, 30. Januar 2022 14:20:10 CET Ayush Singh wrote: > Hello everyone, I am currently working on a Rust Wrapper for KConfig > KDE Framework (https://invent.kde.org/oreki/kconfig-rs) as part of > Season of KDE 2022. For the most part, I have made the wrapping > methods one-to-one with the C++ API. So they use the same arguments > and return types as their C++ counterparts. > > However, during this process, I have come across some methods where I > can change the API in the Rust side to take better advantage of the > Rust type system. [...] > There are more parts of KConfig similar to this. However, I wanted to > know other people's opinions on how faithful should the Wrapper be to > the original library in general. Is it better to have the same > signatures as the underlying library as far as possible? Or is it > better to break away from the library API when the Language allows > having a stricter and 'misuse-resistant' API? In my opinion, language bindings should feel natural to developers who know the language. After all, the main audience for a language binding is the developers programming in this language and not developers who are proficient in the original language. The Rust binding of KConfig would ideally look like any other library written directly in Rust. So, by all means, make use of any features of Rust that make the Rust binding look less like a binding of a C++ library and more like a native Rust library. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Announcing General Availability of Gitlab CI for Linux, FreeBSD and Android
On Sonntag, 28. November 2021 23:07:50 CET Albert Astals Cid wrote: > El dissabte, 27 de novembre de 2021, a les 19:30:08 (CET), Ben Cooksley va escriure: > > As mentioned in the subject, i'm happy to announce the general > > availability > > of native Gitlab CI for all KDE projects for Linux, FreeBSD and Android. That's great news! Thanks, Ben and other admins! > Do we have any plan for "category pages" [1] like in Jenkins? > [1] i.e. something like > https://build.kde.org/job/Applications/view/Platform%20-%20WindowsMSVCQt5.15/ At my old workplace I had set up https://github.com/heikkipora/gitlab-radiator The maintainer was quite responsive to my contributions. It talks to the GitLab API and uses caching to avoid hammering the GitLab server with requests if many people use it. It uses npm which may not be the best/most secure backend. I'm sure there are other Free Software GitLab monitors. GitLab seems to have something similar, but not in the Community Edition. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: New repo in kdereview: kclock
On Donnerstag, 3. Juni 2021 16:23:51 CEST Jonathan Riddell wrote: > On Thu, 13 May 2021 at 09:57, hanyoung wrote: > > Kirigami Add-ons (a runtime dependency of kclock) now have a proper > > release. https://invent.kde.org/libraries/kirigami-addons > > Although KClock now has a release published under stable ( > https://download.kde.org/stable/plasma-mobile/21.05/) there is no stable > release of kirigami-addons and no kdereview submission. That should be > fixed first. Well, there was https://mail.kde.org/pipermail/kde-core-devel/2021-April/091283.html Not sure whether all of Albert's and Nate's comments were addressed. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDiff Bug 436958
On Donnerstag, 13. Mai 2021 07:53:05 CEST Michael Reeves wrote: > That's a crash in the implicit default constructor of QTemporaryFile. I don't think so. > > #10 0x55590227c7bb in SourceData::readAndPreprocess > > (this=0x555903298590, pEncoding=0x555903144ab0, > > bAutoDetectUnicode=true) at > > /home/apol/devel/frameworks/kdiff3/src/SourceData.cpp:351 points to the line Q_ASSERT(!m_fileAccess.isDir()); in SourceData.cpp. https://invent.kde.org/sdk/kdiff3/-/blob/master/src/SourceData.cpp#L351 Regards, Ingo > On Wed, May 12, 2021, 7:30 PM Aleix Pol wrote: > > On Thu, May 13, 2021 at 1:00 AM Michael Reeves > > wrote: > > > Could someone other than myself please have a look at this. > > > > > > https://bugs.kde.org/show_bug.cgi?id=436958 > > > > > > None of these issues affect my system. I strongly suspect a distro > > > specific issue. https://bugs.gentoo.org/show_bug.cgi?id=789330. The > > > offending commit makes no sense as a true root cause. I would like an > > > answer as to what is going on. > > > > Hi, > > I just tried opening it and I get this crash: > > > > #5 0x7f088cf54ef5 in raise () from /usr/lib/libc.so.6 > > #6 0x7f088cf3e862 in abort () from /usr/lib/libc.so.6 > > #7 0x7f088d4dfc51 in qt_message_fatal (message= > pointer>..., context=...) at > > /home/apol/devel/frameworks/qt5/qtbase/src/corelib/global/qlogging.cpp:191 > > 4 > > #8 QMessageLogger::fatal (this=this@entry=0x7ffef2f4b378, > > msg=msg@entry=0x7f088d7ddea0 "ASSERT: \"%s\" in file %s, line %d") at > > /home/apol/devel/frameworks/qt5/qtbase/src/corelib/global/qlogging.cpp:893 > > #9 0x7f088d4df04a in qt_assert (assertion=, > > file=, line=) at > > /home/apol/devel/frameworks/qt5/qtbase/src/corelib/global/qglobal.cpp:3358 > > #10 0x55590227c7bb in SourceData::readAndPreprocess > > (this=0x555903298590, pEncoding=0x555903144ab0, > > bAutoDetectUnicode=true) at > > /home/apol/devel/frameworks/kdiff3/src/SourceData.cpp:351 > > #11 0x5559021a6d5d in KDiff3App::mainInit (this=0x555903379bf0, > > pTotalDiffStatus=0x55590334ae70, inFlags=...) at > > /home/apol/devel/frameworks/kdiff3/src/pdiff.cpp:144 > > #12 0x5559021afecb in KDiff3App::slotFileOpen > > (this=0x555903379bf0) at > > /home/apol/devel/frameworks/kdiff3/src/pdiff.cpp:938 > > #13 0x55590215b154 in KDiff3App::completeInit > > (this=0x555903379bf0, fn1=..., fn2=..., fn3=...) at > > /home/apol/devel/frameworks/kdiff3/src/kdiff3.cpp:519 > > #14 0x55590214c2db in KDiff3Shell::KDiff3Shell > > (this=0x5559031d7400, bCompleteInit=true) at > > /home/apol/devel/frameworks/kdiff3/src/kdiff3_shell.cpp:60 > > #15 0x555902148223 in main (argc=1, argv=0x7ffef2f4d108) at > > /home/apol/devel/frameworks/kdiff3/src/main.cpp:188 signature.asc Description: This is a digitally signed message part.
Re: Koko in KDEReview
On Samstag, 13. März 2021 20:14:26 CET Carl Schwan wrote: > I would like to move Koko to KDEReview. Koko is a convergent image > viewer that works on both Plasma Desktop and Plasma Mobile. It's the > second try of Koko in KDEReview, the first try failed[1] because Koko > didn't really worked with traditional packaging and was too focused > on the mobile usecase. [...] > The repo: https://invent.kde.org/graphics/koko > The repo for the image editor: > https://invent.kde.org/libraries/kquickimageeditor/ (required for koko to > run) I'm a bit confused. As far as I can see, kquickimageeditor is still in playground and does not seem to have passed through KDEReview. I find it very odd to move a project to KDEReview that depends on stuff that hasn't passed through KDEReview. Apparently, neochat which has recently passed through KDEReview also depends on kquickimageeditor. I'm confused. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KOpeningHours in kdereview
On Donnerstag, 10. Dezember 2020 17:56:15 CET Volker Krause wrote: > The most notable feature gap compared to the official specification is > probably school holidays, we lack a collection of international data for > that so far. That only occurs in about 2k out of the 1.8M opening hours > expressions in the full OSM database, so that's not a massive problem in > practice. I'd say that currently the most notable feature gap is lack of knowledge about Corona lock-downs. I guess that currently a massive amount of locations are not open even if the opening hours data in OSM says so. :/ Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Alligator in KDEReview
On Sonntag, 1. November 2020 12:29:43 CET Albert Astals Cid wrote:
> El dijous, 29 d’octubre de 2020, a les 0:34:30 CET, Tobias Fella va
escriure:
> > Since I'm still a beginner at programming with Qt/cpp/qml, I'd
> > appreciate comments or suggestions on my code ;)
>
> You're missing KLocalizedString::setApplicationDomain in your main.cpp
>
> You're not deleteing the Author you create on Entry::Entry, i'm guessing a
> qDeleteAll(m_authors); in the destructor is what you want.
>
> Similarly you seem to also need a qDeleteAll(m_entries) in EntriesModel
> destructor
I strongly suggest not to use raw pointers in C++ code unless you really need
to (e.g. if you create millions of objects and cannot afford the performance
or memory cost). In all other cases you should delegate the object life-time
to C++.
Either use one of the STL smart pointers [1], or, if you insist on Qt, one of
the Qt "equivalents" like QSharedPointer or QScopedPointer.
In the case of Author it would probably be much better to make Author a value-
class. After all, Author is basically just a
struct {
QString name;
QString email;
QString url;
}
Or does it need to be a heavy QObject because of QML? If yes, then you could
also make use of Qt's parent-child-life-cycle-management (see e.g. [2]) and
delegate the deletion of the Author objects to Entry by passing `this` instead
of `nullptr` as parent argument to Author's constructor, i.e. by doing
```
m_authors += new Author(..., this);
```
instead of
```
m_authors += new Author(..., nullptr);
```
By the way, explicitly passing `nullptr` for parent is pretty useless because
`nullptr` is the default value for parent according to the definition of
Author's constructor.
Regards,
Ingo
[1] https://en.cppreference.com/w/cpp/memory
[2] https://doc.qt.io/qt-5/objecttrees.html
signature.asc
Description: This is a digitally signed message part.
Re: CMake kauth_install_* with system kauth and user CMAKE_INSTALL_PREFIX
On Montag, 19. Oktober 2020 17:22:22 CEST Milian Wolff wrote: > On Montag, 19. Oktober 2020 17:21:28 CEST Harald Sitter wrote: > > I'm not sure it's a good idea, but we could treat this like > > KDE_INSTALL_USE_QT_SYS_PATHS. By default we'll simply install to > > $CMAKE_PREFIX/share/polkit-1/actions/ unless explicitly configured with > > KDE_INSTALL_USE_POLKIT_PATHS in which case we'll use whatever polkit uses. > > What sets this apart from qt_syspath of course is that not using the > > polkit path basically never makes sense as it'd be broken. So maybe the > > default state should be ON and when one is sure that polkit isn't needed > > one could turn it OFF. > > Installing something that's never going to be used - why? I would much > rather prefer making it explicit by saying: > > Either you install it to the correct path, or you don't install it at all. FWIW, for a very similar problem (udev rules instead of polkit rules) bluez-qt has the CMAKE flag INSTALL_UDEV_RULE to disable installation of udev rules. If have this in my .kdesrc-buildrc: = options bluez-qt cmake-options -DINSTALL_UDEV_RULE=0 end options = So, maybe add a KDE_INSTALL_POLKIT_RULE[S] (or ..._ACTION[S]) flag to allow disabling the installation of polkit stuff. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Git merge workflow: reverse it?
On Mittwoch, 26. August 2020 09:59:16 CEST Boudewijn Rempt wrote: > On Tuesday, 25 August 2020 23:44:02 CEST you wrote: > > Or you can merge stable to master and be sure you won't forget anything. > > Of course if master changed a lot you can't (easily) do that. But we > > have a lot of repos that don't change very often and merging stable to > > master works very well with them. > > ... > > > The problem is we don't always have a maintainer. A lot of apps are > > community-maintained and if we wouldn't merge stable to master before a > > new release we would reintroduce fixed bugs quite often. > > Basically, what you're saying is that KDE releases a lot of software that > just basically never changes, and apart from some translation work is > actually unmaintained. No. "Doesn't change very often" doesn't mean unmaintained. It could also mean feature-complete (at least from the point of view of the maintainer). The only significant work that still happens is bug fixing. > I don't think that those projects, or rather repositories, since if there's > no work being done, it's hard to see that as a project, should shape > policy. I agree to a certain point because unless the bug is really critical the maintainer could choose to fix the bug only in master. > If a repo can get by with just merging stable to master, I don't think it's > seeing meaningful development -- why should it even be released? Because some bugs were fixed? Boud, please don't look with your Krita glasses on other projects. A small application like Spectacle or something even smaller like the recently proposed markdownpart certainly has very different requirements on project management and software engineering than a large application like Krita. In particular, a small, more or less feature-complete application doesn't require large scale refactoring which would make merging stable to master a painful process. I can see that for Krita merging stable to master isn't a viable workflow. In my opinion, there can't be a one-size-fits-all git merge workflow/policy. Apparently, Krita does already deviate from the current "KDE-wide" "fix in stable and merge stable to master" policy that is challenged in this thread. In my opinion, the decision which policy (of maybe two sensible policies we can agree on) to use for a project should be left to the ones who are doing the work, i.e. for small, largely one-developer (== maintainer) projects it should be left to their maintainer. As for the release managers, they should simply take what's there. Merging stable to master shouldn't be part of their job, in my opinion. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Introducing KDE Activity Filter
On Sonntag, 19. Juli 2020 10:20:56 CEST Adriaan de Groot wrote: > On Tuesday, 14 July 2020 10:57:41 CEST Ingo Klöcker wrote: > > On Dienstag, 14. Juli 2020 10:20:33 CEST Kåre Särs wrote: > > > Is there a way to verify that the yaml file is syntactically correct > > > before > > > pushing the change? > > > > There are loads of YAML linters/validators, online and offline. In fact, > > this would be an opportunity to test-drive the awesome GitLab CI/CD. I > > volunteer to implement this, if sysadmin is okay with this. > > There's a bunch of different tools for YAML validation indeed. It has already been implemented and merged. I'm using the Python package yamllint. > > Or do you mean "semantically correct", i.e. also checking for valid > > projects? > > (From a JSON-schema perspective) You might periodically generate a schema > type that checks the repository-re, for the simple case of |-separated full > repository names. Personally I'd be more inclined to follow Albert's > original question, and change the tool not to eat a RE but a YAML > list-of-repo-names. I didn't implement any semantic validation. I agree that using a list would be more YAML-like. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Introducing KDE Activity Filter
On Dienstag, 14. Juli 2020 10:20:33 CEST Kåre Särs wrote: > Is there a way to verify that the yaml file is syntactically correct before > pushing the change? There are loads of YAML linters/validators, online and offline. In fact, this would be an opportunity to test-drive the awesome GitLab CI/CD. I volunteer to implement this, if sysadmin is okay with this. Or do you mean "semantically correct", i.e. also checking for valid projects? Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Discontinuing legacy infrastructure
Hi Carl, I hope it's okay, that I send my reply to your pm to k-c-d. On Donnerstag, 11. Juni 2020 15:18:18 CEST Carl Schwan wrote: > Le jeudi, juin 11, 2020 1:04 PM, Ingo Klöcker a écrit : > > On Donnerstag, 11. Juni 2020 11:11:48 CEST Ben Cooksley wrote: > > > 2. CGit has been discontinued > > > > > > > > > The CGit instance previously available at cgit.kde.org has now been > > > shutdown and is no longer available. All repository browsing should > > > now take place via Gitlab at https://invent.kde.org/ > > > > Please redirectprojects.kde.org to invent (or shut it down). Currently, > > projects.kde.org shows an empty directory listing. > > https://projects.kde.org/api/ is still used. https://projects.kde.org/ (only this page; nothing below it) could still redirect to https://invent.kde.org/. Showing an empty directory listing at https://projects.kde.org/ seems more like an accident than an intentional change. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Discontinuing legacy infrastructure
On Donnerstag, 11. Juni 2020 11:11:48 CEST Ben Cooksley wrote: > 2) CGit has been discontinued > > The CGit instance previously available at cgit.kde.org has now been > shutdown and is no longer available. All repository browsing should > now take place via Gitlab at https://invent.kde.org/ Please redirect projects.kde.org to invent (or shut it down). Currently, projects.kde.org shows an empty directory listing. Regards, Ingo signature.asc Description: This is a digitally signed message part.
