KDE CI: Frameworks » kio » kf5-qt5 FreeBSDQt5.15 - Build # 874 - Fixed!
BUILD SUCCESS Build URL https://build.kde.org/job/Frameworks/job/kio/job/kf5-qt5%20FreeBSDQt5.15/874/ Project: kf5-qt5 FreeBSDQt5.15 Date of build: Mon, 21 Jun 2021 01:23:06 + Build duration: 3 min 55 sec and counting JUnit Tests Name: projectroot Failed: 0 test(s), Passed: 59 test(s), Skipped: 0 test(s), Total: 59 test(s)Name: projectroot.autotests Failed: 0 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 6 test(s)Name: projectroot.src.ioslaves.trash Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot.src.kpasswdserver Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)
Re: Problem with ksycoca not being regenerated under flatpak
On Sun, Jun 20, 2021 at 11:29 AM Albert Astals Cid wrote: > > El diumenge, 13 de desembre de 2020, a les 22:15:26 (CEST), Albert Astals Cid > va escriure: > > El dissabte, 12 de desembre de 2020, a les 22:59:58 CET, David Faure va > > escriure: > > > Time flies, sorry for the delay. > > > > > > On samedi 12 septembre 2020 19:44:45 CET Albert Astals Cid wrote: > > > > flatpak mounts all files as if created on January 1st 1970. > > > > > > Isn't that a bug in itself? Why doesn't it preserve mtimes? > > > > I don't know, because reasons i guess, i never fully understood the answers > > i got on the flatpak mailing list > > > > https://lists.freedesktop.org/archives/flatpak/2020-October/002049.html > > > > https://lists.freedesktop.org/archives/flatpak/2020-November/002057.html > > > > > > > > > This has the unfortunate effect that when we add new plugins to a > > > > flatpak > > > > (i.e. we just added markdown preview support in kate), they are not seen > > > > because ksycoca doesn't feel the need to regenerate itself (the sycoca > > > > file > > > > for flatpak is written "outside" flatpak container and thus has a newer > > > > date). > > > > > > > > I remember talking about this probably a year ago at least with Aleix, > > > > but i > > > > guess we did not come up with any solution since it's still broken :D > > > > > > > > I don't know much about sycoca, but can we make it so the cache always > > > > get > > > > regenerated on app launch when run under flatpak? > > > > > > Is there no way to manually "touch" a directory after adding new files? > > > > > > Otherwise, the hack you have in mind could be implemented as in the > > > attached > > > patch. Untested, except that it compiles. > > > > I'll test the patch at some point, thanks for caring :) > > So I did *not* test the patch, but I got someone else to test it > https://github.com/flathub/org.kde.kdenlive/issues/118#issuecomment-864382857 > > And it seems to solve the problem :) > > Big question left is, should we apply that patch you made directly in > KService or do you prefer we apply it only when compiling the flatpak runtime? I would much prefer if we didn't patch in the packaging. If there's risk in having this outside of flatpak, I'd ifdef it. Aleix
KDE CI: Frameworks » kio » kf5-qt5 FreeBSDQt5.15 - Build # 873 - Still Unstable!
BUILD UNSTABLE Build URL https://build.kde.org/job/Frameworks/job/kio/job/kf5-qt5%20FreeBSDQt5.15/873/ Project: kf5-qt5 FreeBSDQt5.15 Date of build: Sun, 20 Jun 2021 12:17:48 + Build duration: 9 min 51 sec and counting JUnit Tests Name: projectroot Failed: 1 test(s), Passed: 58 test(s), Skipped: 0 test(s), Total: 59 test(s)Failed: projectroot.autotests.commandlauncherjob_forkingtestName: projectroot.autotests Failed: 0 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 6 test(s)Name: projectroot.src.ioslaves.trash Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot.src.kpasswdserver Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)
Re: KF5 modules development branches now build in C++17 mode (but keep public headers compatible)
On 20/06/2021 12:36, Albert Astals Cid wrote: [...] Semi-related question, does anyone know why we're not using set(CMAKE_CXX_EXTENSIONS OFF) ? Good question. Given there _are_ differences between libstdc++ (gcc) and libc++ (clang) and sometimes we have issues due to those differences, it does make sense to disable compiler specific extensions. Cheers, Albert > -- Ahmad Samir
Mentioning the required standard in API docs (was: Re: KF5 modules development branches now build in C++17 mode)
Am Sonntag, 20. Juni 2021, 12:16:33 CEST schrieb Friedrich W. H. Kossebau: > As KF5 promises ABI & source backwards-compatibility for the KF5 series to > its consumers, public KF headers need to stay compatible with projects > using C++11 (or C++14). > So in public headers C++17 features can only be used for new API and also > needs to be guarded properly by respective preprocessor macros to not be > seen in C++<17 usages of KF headers. On a related note, we also need to think about how to mark C++17-only features (or any counterparts) in the KF API documentation, so developers know from first read on whether some KF API fits their project standards. Something like "C++17 only", " etc. Myself I do not know some good examples in other documentation right now to copy from, but definitely IMHO we should provide this in ours. A first related TODO note has been created here: https://invent.kde.org/frameworks/kapidox/-/issues/7 If you have proposals for how to do that or examples in other existing documentation to copy from, please add a note there. Cheers Friedrich
Re: KF5 modules development branches now build in C++17 mode (but keep public headers compatible)
El diumenge, 20 de juny de 2021, a les 12:16:33 (CEST), Friedrich W. H. Kossebau va escriure: > Hi, > > small heads-up for everyone: as of yesterday, KDEFrameworksCompilerSettings > from current ECM development branch now sets > set(CMAKE_CXX_STANDARD 17) > set(CMAKE_CXX_STANDARD_REQUIRED TRUE) Semi-related question, does anyone know why we're not using set(CMAKE_CXX_EXTENSIONS OFF) ? Cheers, Albert > for all KF modules (triggered by required ECM 5.84.0 version, which was also > bumped yesterday in all KF module development branches already to activate > the > setting). > Any custom CMAKE_CXX_STANDARD settings as before present in some KF modules > have been removed as well, so all KF modules code should build now complying > to the C++17 standards, so everyone can also take advantage of those in new > code for KF modules from now on. > > > BEWARE (just to emphasize the obvious to you, so it can be referenced ;) ): > > As KF5 promises ABI & source backwards-compatibility for the KF5 series to > its > consumers, public KF headers need to stay compatible with projects using > C++11 > (or C++14). > So in public headers C++17 features can only be used for new API and also > needs to be guarded properly by respective preprocessor macros to not be seen > in C++<17 usages of KF headers. > > Cheers > Friedrich > > >
KF5 modules development branches now build in C++17 mode (but keep public headers compatible)
Hi, small heads-up for everyone: as of yesterday, KDEFrameworksCompilerSettings from current ECM development branch now sets set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED TRUE) for all KF modules (triggered by required ECM 5.84.0 version, which was also bumped yesterday in all KF module development branches already to activate the setting). Any custom CMAKE_CXX_STANDARD settings as before present in some KF modules have been removed as well, so all KF modules code should build now complying to the C++17 standards, so everyone can also take advantage of those in new code for KF modules from now on. BEWARE (just to emphasize the obvious to you, so it can be referenced ;) ): As KF5 promises ABI & source backwards-compatibility for the KF5 series to its consumers, public KF headers need to stay compatible with projects using C++11 (or C++14). So in public headers C++17 features can only be used for new API and also needs to be guarded properly by respective preprocessor macros to not be seen in C++<17 usages of KF headers. Cheers Friedrich
Re: Problem with ksycoca not being regenerated under flatpak
El diumenge, 13 de desembre de 2020, a les 22:15:26 (CEST), Albert Astals Cid va escriure: > El dissabte, 12 de desembre de 2020, a les 22:59:58 CET, David Faure va > escriure: > > Time flies, sorry for the delay. > > > > On samedi 12 septembre 2020 19:44:45 CET Albert Astals Cid wrote: > > > flatpak mounts all files as if created on January 1st 1970. > > > > Isn't that a bug in itself? Why doesn't it preserve mtimes? > > I don't know, because reasons i guess, i never fully understood the answers i > got on the flatpak mailing list > > https://lists.freedesktop.org/archives/flatpak/2020-October/002049.html > > https://lists.freedesktop.org/archives/flatpak/2020-November/002057.html > > > > > > This has the unfortunate effect that when we add new plugins to a flatpak > > > (i.e. we just added markdown preview support in kate), they are not seen > > > because ksycoca doesn't feel the need to regenerate itself (the sycoca > > > file > > > for flatpak is written "outside" flatpak container and thus has a newer > > > date). > > > > > > I remember talking about this probably a year ago at least with Aleix, > > > but i > > > guess we did not come up with any solution since it's still broken :D > > > > > > I don't know much about sycoca, but can we make it so the cache always get > > > regenerated on app launch when run under flatpak? > > > > Is there no way to manually "touch" a directory after adding new files? > > > > Otherwise, the hack you have in mind could be implemented as in the > > attached > > patch. Untested, except that it compiles. > > I'll test the patch at some point, thanks for caring :) So I did *not* test the patch, but I got someone else to test it https://github.com/flathub/org.kde.kdenlive/issues/118#issuecomment-864382857 And it seems to solve the problem :) Big question left is, should we apply that patch you made directly in KService or do you prefer we apply it only when compiling the flatpak runtime? Cheers, Albert > > Cheers, > Albert > > > >
KDE CI: Frameworks » plasma-framework » kf5-qt5 FreeBSDQt5.15 - Build # 496 - Fixed!
BUILD SUCCESS Build URL https://build.kde.org/job/Frameworks/job/plasma-framework/job/kf5-qt5%20FreeBSDQt5.15/496/ Project: kf5-qt5 FreeBSDQt5.15 Date of build: Sun, 20 Jun 2021 08:02:14 + Build duration: 2 min 26 sec and counting JUnit Tests Name: projectroot Failed: 0 test(s), Passed: 11 test(s), Skipped: 0 test(s), Total: 11 test(s)
