KDE CI: Frameworks plasma-framework kf5-qt5 WindowsQt5.7 - Build # 44 - Still Failing!
BUILD FAILURE Build URL https://build.kde.org/job/Frameworks%20plasma-framework%20kf5-qt5%20WindowsQt5.7/44/ Project: Frameworks plasma-framework kf5-qt5 WindowsQt5.7 Date of build: Sun, 25 Jun 2017 05:03:37 + Build duration: 6 min 55 sec and counting CONSOLE OUTPUT [...truncated 637.39 KB...]C:\Qt\5.7\msvc2015_64\include\QtCore/qmetatype.h(764): note: while compiling class template member function 'void *QtMetaTypePrivate::QMetaTypeFunctionHelper::Construct(void *,const void *)'with[T=Plasma::Package]C:\Qt\5.7\msvc2015_64\include\QtCore/qmetatype.h(1695): note: see reference to function template instantiation 'void *QtMetaTypePrivate::QMetaTypeFunctionHelper::Construct(void *,const void *)' being compiledwith[T=Plasma::Package]C:\Qt\5.7\msvc2015_64\include\QtCore/qmetatype.h(1696): note: see reference to class template instantiation 'QtMetaTypePrivate::QMetaTypeFunctionHelper' being compiledwith[T=Plasma::Package]C:\Qt\5.7\msvc2015_64\include\QtCore/qmetatype.h(1725): note: see reference to function template instantiation 'int qRegisterNormalizedMetaType(const QByteArray &,T *,QtPrivate::MetaTypeDefinedHelper::DefinedType)' being compiledwith[T=Plasma::Package]C:\JENKIN~1\WORKSP~1\FRAMEW~4.7\src\plasma/package.h(374): note: see reference to function template instantiation 'int qRegisterMetaType(const char *,T *,QtPrivate::MetaTypeDefinedHelper::DefinedType)' being compiledwith[T=Plasma::Package]C:\Qt\5.7\msvc2015_64\include\QtCore/qmetatype.h(767): warning C4996: 'Plasma::Package::Package': was declared deprecatedC:\JENKIN~1\WORKSP~1\FRAMEW~4.7\src\plasma/package.h(95): note: see declaration of 'Plasma::Package::Package'C:\Qt\5.7\msvc2015_64\include\QtCore/qmetatype.h(766): warning C4996: 'Plasma::Package::Package': was declared deprecatedC:\JENKIN~1\WORKSP~1\FRAMEW~4.7\src\plasma/package.h(107): note: see declaration of 'Plasma::Package::Package'C:\Qt\5.7\msvc2015_64\include\QtCore/qmetatype.h(764): note: while compiling class template member function 'void *QtMetaTypePrivate::QMetaTypeFunctionHelper::Construct(void *,const void *)'with[T=Plasma::Package]C:\Qt\5.7\msvc2015_64\include\QtCore/qmetatype.h(1695): note: see reference to function template instantiation 'void *QtMetaTypePrivate::QMetaTypeFunctionHelper::Construct(void *,const void *)' being compiledwith[T=Plasma::Package]C:\Qt\5.7\msvc2015_64\include\QtCore/qmetatype.h(1696): note: see reference to class template instantiation 'QtMetaTypePrivate::QMetaTypeFunctionHelper' being compiledwith[T=Plasma::Package]C:\Qt\5.7\msvc2015_64\include\QtCore/qmetatype.h(1725): note: see reference to function template instantiation 'int qRegisterNormalizedMetaType(const QByteArray &,T *,QtPrivate::MetaTypeDefinedHelper::DefinedType)' being compiledwith[T=Plasma::Package]C:\JENKIN~1\WORKSP~1\FRAMEW~4.7\src\plasma/package.h(374): note: see reference to function template instantiation 'int qRegisterMetaType(const char *,T *,QtPrivate::MetaTypeDefinedHelper::DefinedType)' being compiledwith[T=Plasma::Package]C:\Qt\5.7\msvc2015_64\include\QtCore/qmetatype.h(767): warning C4996: 'Plasma::Package::Package': was declared deprecatedC:\JENKIN~1\WORKSP~1\FRAMEW~4.7\src\plasma/package.h(95): note: see declaration of 'Plasma::Package::Package'C:\Qt\5.7\msvc2015_64\include\QtCore/qmetatype.h(766): warning C4996: 'Plasma::Package::Package': was declared deprecatedC:\JENKIN~1\WORKSP~1\FRAMEW~4.7\src\plasma/package.h(107): note: see declaration of 'Plasma::Package::Package'C:\Qt\5.7\msvc2015_64\include\QtCore/qmetatype.h(764): note: while compiling class template member function 'void *QtMetaTypePrivate::QMetaTypeFunctionHelper::Construct(void *,const void *)'with[T=Plasma::Package]C:\Qt\5.7\msvc2015_64\include\QtCore/qmetatype.h(1695): note: see reference to function template instantiation 'void *QtMetaTypePrivate::QMetaTypeFunctionHelper::Construct(void *,const void *)' being compiledwith[T=Plasma::Package]C:\Qt\5.7\msvc2015_64\include\QtCore/qmetatype.h(1696): note: see reference to class template instantiation 'QtMetaTypePrivate::QMetaTypeFunctionHelper' being compiledwith[T=Plasma::Package]C:\Qt\5.7\msvc2015_64\include\QtCore/qmetatype.h(1725): note: see reference to function template instantiation 'int qRegisterNormalizedMetaType(const QByteArray &,T *,QtPrivate::MetaTypeDefinedHelper::DefinedType)' being compiledwith[T=Plasma::Package]C:\JENKIN~1\WORKSP~1\FRAMEW~4.7\src\plasma/package.h(374): note: see reference to function
D6076: Do not depend on bash uncessarily, and do not validate icons by default.
aacid added a comment. I don't think i know enough sh to give it a "this is compatible with basic sh", but i guess that if it works you can commit it. Only thing is that maybe you don't really need to de-bash optimize-svg.sh and icons-dark/light2Dark since they seem things you run manually? but if they still work on other non bash shells i guess it doesn't hurt either. REPOSITORY R266 Breeze Icons REVISION DETAIL https://phabricator.kde.org/D6076 To: adridg, #freebsd, winterz, tcberner Cc: adridg, aacid, rakuco, #frameworks
Re: Kirigami in Frameworks
On Sun, Jun 25, 2017 at 8:44 AM, David Faure wrote: > On samedi 24 juin 2017 11:15:25 CEST Ben Cooksley wrote: >> Please check the new CI at https://build-sandbox.kde.org/ for the >> current state of affairs. > > This doesn't appear to have kirigami at all? Kirigami is currently in Extragear, and coverage for Extragear projects must be explicitly requested by the maintainers of a project (as outlined in my prior emails regarding the new CI). No such request has been received for Kirigami. > > -- > David Faure, fa...@kde.org, http://www.davidfaure.fr > Working on KDE Frameworks 5 > Cheers, Ben
Re: Kirigami in Frameworks
On samedi 24 juin 2017 11:15:25 CEST Ben Cooksley wrote: > Please check the new CI at https://build-sandbox.kde.org/ for the > current state of affairs. This doesn't appear to have kirigami at all? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: KDE CI: Frameworks kfilemetadata kf5-qt5 XenialQt5.7 - Build # 11 - Failure!
This is due to a breakage in Neon, i've asked the Neon developers to fix it. Regards, Ben On Sun, Jun 25, 2017 at 4:00 AM, wrote: > *BUILD FAILURE* > Build URL https://build-sandbox.kde.org/job/Frameworks% > 20kfilemetadata%20kf5-qt5%20XenialQt5.7/11/ > Project: Frameworks kfilemetadata kf5-qt5 XenialQt5.7 > Date of build: Sat, 24 Jun 2017 15:59:31 + > Build duration: 1 min 5 sec and counting > * CONSOLE OUTPUT * > [...truncated 302.55 KB...] > ^ > /usr/include/taglib/id3v2tag.h:173:28: warning: 'virtual unsigned int > TagLib::ID3v2::Tag::track() const' can be marked override > [-Wsuggest-override] > virtual unsigned int track() const; > ^ > /usr/include/taglib/id3v2tag.h:175:20: warning: 'virtual void > TagLib::ID3v2::Tag::setTitle(const TagLib::String&)' can be marked > override [-Wsuggest-override] > virtual void setTitle(const String &s); > ^ > /usr/include/taglib/id3v2tag.h:176:20: warning: 'virtual void > TagLib::ID3v2::Tag::setArtist(const TagLib::String&)' can be marked > override [-Wsuggest-override] > virtual void setArtist(const String &s); > ^ > /usr/include/taglib/id3v2tag.h:177:20: warning: 'virtual void > TagLib::ID3v2::Tag::setAlbum(const TagLib::String&)' can be marked > override [-Wsuggest-override] > virtual void setAlbum(const String &s); > ^ > /usr/include/taglib/id3v2tag.h:178:20: warning: 'virtual void > TagLib::ID3v2::Tag::setComment(const TagLib::String&)' can be marked > override [-Wsuggest-override] > virtual void setComment(const String &s); > ^ > /usr/include/taglib/id3v2tag.h:179:20: warning: 'virtual void > TagLib::ID3v2::Tag::setGenre(const TagLib::String&)' can be marked > override [-Wsuggest-override] > virtual void setGenre(const String &s); > ^ > /usr/include/taglib/id3v2tag.h:180:20: warning: 'virtual void > TagLib::ID3v2::Tag::setYear(unsigned int)' can be marked override > [-Wsuggest-override] > virtual void setYear(unsigned int i); > ^ > /usr/include/taglib/id3v2tag.h:181:20: warning: 'virtual void > TagLib::ID3v2::Tag::setTrack(unsigned int)' can be marked override > [-Wsuggest-override] > virtual void setTrack(unsigned int i); > ^ > /usr/include/taglib/id3v2tag.h:183:20: warning: 'virtual bool > TagLib::ID3v2::Tag::isEmpty() const' can be marked override > [-Wsuggest-override] > virtual bool isEmpty() const; > ^ > In file included from /home/jenkins/workspace/Frameworks kfilemetadata > kf5-qt5 XenialQt5.7/src/writers/taglibwriter.cpp:6:0: > /usr/include/taglib/fileref.h:92:25: warning: 'class > TagLib::FileRef::FileTypeResolver' > has virtual functions and accessible non-virtual destructor > [-Wnon-virtual-dtor] > class TAGLIB_EXPORT FileTypeResolver > ^ > Scanning dependencies of target externalextractortest > [ 62%] Building CXX object autotests/CMakeFiles/externalextractortest.dir/ > externalextractortest.cpp.o > [ 63%] Linking CXX shared module kfilemetadata_odfextractor.so > [ 63%] Built target kfilemetadata_odfextractor > [ 64%] Building CXX object src/writers/CMakeFiles/ > kfilemetadata_taglibwriter.dir/kfilemetadata_taglibwriter_automoc.cpp.o > [ 65%] Building CXX object autotests/CMakeFiles/ > externalwritertest.dir/__/src/externalwriter.cpp.o > Scanning dependencies of target indexextractortest > [ 66%] Building CXX object autotests/CMakeFiles/indexextractortest.dir/ > indexerextractortests.cpp.o > [ 67%] Building CXX object autotests/CMakeFiles/epubextractortest.dir/ > epubextractortest_automoc.cpp.o > [ 68%] Building CXX object autotests/CMakeFiles/ > officeextractortest.dir/__/src/extractors/office2007extractor.cpp.o > [ 69%] Building CXX object autotests/CMakeFiles/officeextractortest.dir/ > officeextractortest_automoc.cpp.o > [ 70%] Building CXX object autotests/CMakeFiles/ > externalextractortest.dir/__/src/externalextractor.cpp.o > [ 71%] Linking CXX shared module kfilemetadata_taglibwriter.so > [ 72%] Building CXX object autotests/CMakeFiles/ > odfextractortest.dir/__/src/extractors/odfextractor.cpp.o > [ 72%] Built target kfilemetadata_taglibwriter > Scanning dependencies of target extractorcollectiontest > [ 73%] Building CXX object autotests/CMakeFiles/ > extractorcollectiontest.dir/extractorcollectiontest.cpp.o > [ 74%] Building CXX object autotests/CMakeFiles/externalwritertest.dir/ > externalwritertest_automoc.cpp.o > [ 75%] Linking CXX executable epubextractortest > /usr/bin/ld: warning: libzip.so.4, needed by > /usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib/libepub.so, > not found (try using -rpath or -rpath-link) > /usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib/libepub.so: undefined > reference to `zip_strerror' > /usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib/libepub.so: undefined > reference to `zip_stat_init' > /usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib/libepub.so: undefined > reference to `zip_close' > /usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib/libepub.so: undefined > reference to `zip_error_to_str' > /usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib/libepub.so: undefined > reference to `zip_fread' > /usr/lib/gcc/
Re: Kirigami in Frameworks
On Sun, Jun 25, 2017 at 1:27 AM, David Faure wrote: > On samedi 24 juin 2017 11:52:22 CEST Marco Martin wrote: >> > from requiring Qt 5.7. >> > This Qt version difference creates an issue for the CI though, as can be >> > seen at https://build.kde.org/job/kirigami%20master%20stable-kf5-qt5/ >> >> so it could be released as a framework anyways, good >> If it helps, I could even let it build under 5.6, as everything that >> depends on 5.7 are qml files, which is a runtime dependency (on a 5.6 >> system would just install a bunch of dead code in form of qml files) >> Alternatively, there is still an old branch around that works on Qt >> 5.6, is pretty much dead, but we still do a bugfix in there every now >> and then, that one could be built on the 5.6 version of ci > > That's one solution. But I'm not sure that the new CI works the same way > anyway, maybe it solves this differently. The new CI system uses the same platform for both current development and stable branches of a given Product at the moment, and in the case of Frameworks all three images (for Linux, FreeBSD and Windows) all use Qt 5.7. > >> uh, leftover, both checks on THEME can be removed safely > > OK, thanks. > >> as DESKTOP_ENABLED and PLASMA_ENABLED install stuff that has more >> dependencies (always runtime tough and just for the looks, never new >> api/functionality) is it ok leaving it there built conditionally >> (easier to maintain) or should be splitted in another repo? > > Seems fine to me. > >> > I noticed that DESKTOP_ENABLED installs a file called >> > styles/org.kde.desktop, which matches a runtime error I've seen for some >> > time now, e.g. at QtCreator >> startup: >> > QtCreator(12888)/default QQuickControlSettings1::QQuickControlSettings1: >> WARNING: Cannot find style "org.kde.desktop" - fallback: >> "/d/qt/5/kde/build/qtbase/qml/QtQuick/Controls/Styles/Desktop" >> >> basically kirigami has a style that is called org.kde.desktop for >> desktop systems, that matches the style we did for QtQuickControls2 >> for desktop systems as well, as Qt is not interested to do a desktop >> specific style for qtquickcontrols2 themselves, >> however, >> the environment variable to set the style of both qtquickcontrols1 and >> 2 style is QT_QUICK_CONTROLS_STYLE, which we set in startkde > > Right, that's set to org.kde.desktop indeed. > >> the default style for QtQuickControlsStyle1 is "Desktop" >> we could have called this style "Desktop" as well so all would have >> aligned nicely, but that could be quite dangerous, as Qt coulddecide >> any moment that they indeed want to do a style called "Desktop" for >> qqc2, at which point it would conflict, so having the org.kde prefix >> was the safe route. > > Well, we could also rename ours when/if the conflict occurs? > >> QtQuickControls1 at this moment doesn't find org.kde.desktop, so just >> falls back to its default "Desktop" and everything keeps working as >> expected. > > So the heart of the issue is that both QQC1 and QQC2 use the same environment > variable, which is kind of stupid because nothing guarantees that a style with > that name will exist for both. How about introducing a > QT_QUICK_CONTROLS_2_STYLE in Qt? > >> One way to silence this could be when the qtquickcontrols2 >> theme installs into qt's qqc2 > > If you mean $QTDIR, that's not my case. The plugin is found via > QML2_IMPORT_PATH I suppose. > >> , to install also an org.kde.desktop >> symlink in QtQuickControls1 that just points to "Desktop" (note that >> style is not in the kirigami repository, kirigami has themes with the >> same name because it's an extension on top of qtquickcontrols2) > > That sounds good, if it can be done. > >> > I enabled BUILD_EXAMPLES and got a nice example "kirigami2gallery" built >> > as a result, but why is it under the android subdirectory? >> >> It has some android specific things, like providing a manifest.xml and >> some optional qtandroidextras usage for integration when compiled >> there, but it's intended to be multiplatform, so may make sesie to >> enable it. > > Then I don't think it should be under an android subdir. > A multiplatform app with extra stuff for android integration is still > multiplatform in the first place. > >> talking about examples, do you think is better to build them with a >> flag on the top cmake as is now, or provide a separate standalone >> cmake file under examples/ ? > > Much better the way you did it, it's how I see it done in most other > frameworks. > It makes it easy to enable the building of examples once and for all in > kdesrc-buildrc for instance, to make sure they keep compiling and so that they > are available for testing. > In fact, I wonder if the CI shouldn't set BUILD_EXAMPLES=ON in all frameworks > that have that option... (4 currently, 5 with kirigami). > > -- > David Faure, fa...@kde.org, http://www.davidfaure.fr > Working on KDE Frameworks 5 > Regards, Ben
KDE CI: Frameworks kfilemetadata kf5-qt5 XenialQt5.7 - Build # 11 - Failure!
BUILD FAILURE Build URL https://build-sandbox.kde.org/job/Frameworks%20kfilemetadata%20kf5-qt5%20XenialQt5.7/11/ Project: Frameworks kfilemetadata kf5-qt5 XenialQt5.7 Date of build: Sat, 24 Jun 2017 15:59:31 + Build duration: 1 min 5 sec and counting CONSOLE OUTPUT [...truncated 302.55 KB...]^/usr/include/taglib/id3v2tag.h:173:28: warning: 'virtual unsigned int TagLib::ID3v2::Tag::track() const' can be marked override [-Wsuggest-override] virtual unsigned int track() const;^/usr/include/taglib/id3v2tag.h:175:20: warning: 'virtual void TagLib::ID3v2::Tag::setTitle(const TagLib::String&)' can be marked override [-Wsuggest-override] virtual void setTitle(const String &s);^/usr/include/taglib/id3v2tag.h:176:20: warning: 'virtual void TagLib::ID3v2::Tag::setArtist(const TagLib::String&)' can be marked override [-Wsuggest-override] virtual void setArtist(const String &s);^/usr/include/taglib/id3v2tag.h:177:20: warning: 'virtual void TagLib::ID3v2::Tag::setAlbum(const TagLib::String&)' can be marked override [-Wsuggest-override] virtual void setAlbum(const String &s);^/usr/include/taglib/id3v2tag.h:178:20: warning: 'virtual void TagLib::ID3v2::Tag::setComment(const TagLib::String&)' can be marked override [-Wsuggest-override] virtual void setComment(const String &s);^/usr/include/taglib/id3v2tag.h:179:20: warning: 'virtual void TagLib::ID3v2::Tag::setGenre(const TagLib::String&)' can be marked override [-Wsuggest-override] virtual void setGenre(const String &s);^/usr/include/taglib/id3v2tag.h:180:20: warning: 'virtual void TagLib::ID3v2::Tag::setYear(unsigned int)' can be marked override [-Wsuggest-override] virtual void setYear(unsigned int i);^/usr/include/taglib/id3v2tag.h:181:20: warning: 'virtual void TagLib::ID3v2::Tag::setTrack(unsigned int)' can be marked override [-Wsuggest-override] virtual void setTrack(unsigned int i);^/usr/include/taglib/id3v2tag.h:183:20: warning: 'virtual bool TagLib::ID3v2::Tag::isEmpty() const' can be marked override [-Wsuggest-override] virtual bool isEmpty() const;^In file included from /home/jenkins/workspace/Frameworks kfilemetadata kf5-qt5 XenialQt5.7/src/writers/taglibwriter.cpp:6:0:/usr/include/taglib/fileref.h:92:25: warning: 'class TagLib::FileRef::FileTypeResolver' has virtual functions and accessible non-virtual destructor [-Wnon-virtual-dtor] class TAGLIB_EXPORT FileTypeResolver ^Scanning dependencies of target externalextractortest[ 62%] Building CXX object autotests/CMakeFiles/externalextractortest.dir/externalextractortest.cpp.o[ 63%] Linking CXX shared module kfilemetadata_odfextractor.so[ 63%] Built target kfilemetadata_odfextractor[ 64%] Building CXX object src/writers/CMakeFiles/kfilemetadata_taglibwriter.dir/kfilemetadata_taglibwriter_automoc.cpp.o[ 65%] Building CXX object autotests/CMakeFiles/externalwritertest.dir/__/src/externalwriter.cpp.oScanning dependencies of target indexextractortest[ 66%] Building CXX object autotests/CMakeFiles/indexextractortest.dir/indexerextractortests.cpp.o[ 67%] Building CXX object autotests/CMakeFiles/epubextractortest.dir/epubextractortest_automoc.cpp.o[ 68%] Building CXX object autotests/CMakeFiles/officeextractortest.dir/__/src/extractors/office2007extractor.cpp.o[ 69%] Building CXX object autotests/CMakeFiles/officeextractortest.dir/officeextractortest_automoc.cpp.o[ 70%] Building CXX object autotests/CMakeFiles/externalextractortest.dir/__/src/externalextractor.cpp.o[ 71%] Linking CXX shared module kfilemetadata_taglibwriter.so[ 72%] Building CXX object autotests/CMakeFiles/odfextractortest.dir/__/src/extractors/odfextractor.cpp.o[ 72%] Built target kfilemetadata_taglibwriterScanning dependencies of target extractorcollectiontest[ 73%] Building CXX object autotests/CMakeFiles/extractorcollectiontest.dir/extractorcollectiontest.cpp.o[ 74%] Building CXX object autotests/CMakeFiles/externalwritertest.dir/externalwritertest_automoc.cpp.o[ 75%] Linking CXX executable epubextractortest/usr/bin/ld: warning: libzip.so.4, needed by /usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib/libepub.so, not found (try using -rpath or -rpath-link)/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib/libepub.so: undefined reference to `zip_strerror'/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib/libepub.so: undefined reference to `zip_stat_init'/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib/libepub.so: undefined reference to `zip_close'/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib/libepub.so: undefined reference to `zip_error_to_str'/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib/libepub.so: undefined reference to `zip_fread'/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib/libepub.so: undefined reference
D6366: Fix configure with Qt5Multimedia disabled.
This revision was automatically updated to reflect the committed changes. Closed by commit R286:f30fede21bf0: Fix configure with Qt5Multimedia disabled. (authored by palimaka). REPOSITORY R286 KFileMetaData CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D6366?vs=15810&id=15821 REVISION DETAIL https://phabricator.kde.org/D6366 AFFECTED FILES CMakeLists.txt To: palimaka, #frameworks, mgallien Cc: mgallien, #frameworks
D6366: Fix configure with Qt5Multimedia disabled.
mgallien accepted this revision. mgallien added a comment. This revision is now accepted and ready to land. Thanks for the help. I did not knew this could be wrong. REPOSITORY R286 KFileMetaData BRANCH master REVISION DETAIL https://phabricator.kde.org/D6366 To: palimaka, #frameworks, mgallien Cc: mgallien, #frameworks
D6076: Do not depend on bash uncessarily, and do not validate icons by default.
adridg updated this revision to Diff 15820. adridg added a comment. Make the diff smaller: only de-bash it, and save make-validation-optional for a later patch. REPOSITORY R266 Breeze Icons CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D6076?vs=15116&id=15820 BRANCH arcpatch-D6076 REVISION DETAIL https://phabricator.kde.org/D6076 AFFECTED FILES CMakeLists.txt icons-dark/light2Dark optimize-svg.sh validate_svg.sh To: adridg, #freebsd, winterz, tcberner Cc: adridg, aacid, rakuco, #frameworks
D6076: Do not depend on bash uncessarily, and do not validate icons by default.
adridg commandeered this revision. adridg added a reviewer: tcberner. adridg added a comment. Taking over to follow up Albert's suggestion -- this could be two patches, one to de-bash it, one to make validation optional. REPOSITORY R266 Breeze Icons REVISION DETAIL https://phabricator.kde.org/D6076 To: adridg, #freebsd, winterz, tcberner Cc: adridg, aacid, rakuco, #frameworks
Re: Kirigami in Frameworks
On samedi 24 juin 2017 11:52:22 CEST Marco Martin wrote: > > from requiring Qt 5.7. > > This Qt version difference creates an issue for the CI though, as can be > > seen at https://build.kde.org/job/kirigami%20master%20stable-kf5-qt5/ > > so it could be released as a framework anyways, good > If it helps, I could even let it build under 5.6, as everything that > depends on 5.7 are qml files, which is a runtime dependency (on a 5.6 > system would just install a bunch of dead code in form of qml files) > Alternatively, there is still an old branch around that works on Qt > 5.6, is pretty much dead, but we still do a bugfix in there every now > and then, that one could be built on the 5.6 version of ci That's one solution. But I'm not sure that the new CI works the same way anyway, maybe it solves this differently. > uh, leftover, both checks on THEME can be removed safely OK, thanks. > as DESKTOP_ENABLED and PLASMA_ENABLED install stuff that has more > dependencies (always runtime tough and just for the looks, never new > api/functionality) is it ok leaving it there built conditionally > (easier to maintain) or should be splitted in another repo? Seems fine to me. > > I noticed that DESKTOP_ENABLED installs a file called > > styles/org.kde.desktop, which matches a runtime error I've seen for some > > time now, e.g. at QtCreator > startup: > > QtCreator(12888)/default QQuickControlSettings1::QQuickControlSettings1: > WARNING: Cannot find style "org.kde.desktop" - fallback: > "/d/qt/5/kde/build/qtbase/qml/QtQuick/Controls/Styles/Desktop" > > basically kirigami has a style that is called org.kde.desktop for > desktop systems, that matches the style we did for QtQuickControls2 > for desktop systems as well, as Qt is not interested to do a desktop > specific style for qtquickcontrols2 themselves, > however, > the environment variable to set the style of both qtquickcontrols1 and > 2 style is QT_QUICK_CONTROLS_STYLE, which we set in startkde Right, that's set to org.kde.desktop indeed. > the default style for QtQuickControlsStyle1 is "Desktop" > we could have called this style "Desktop" as well so all would have > aligned nicely, but that could be quite dangerous, as Qt coulddecide > any moment that they indeed want to do a style called "Desktop" for > qqc2, at which point it would conflict, so having the org.kde prefix > was the safe route. Well, we could also rename ours when/if the conflict occurs? > QtQuickControls1 at this moment doesn't find org.kde.desktop, so just > falls back to its default "Desktop" and everything keeps working as > expected. So the heart of the issue is that both QQC1 and QQC2 use the same environment variable, which is kind of stupid because nothing guarantees that a style with that name will exist for both. How about introducing a QT_QUICK_CONTROLS_2_STYLE in Qt? > One way to silence this could be when the qtquickcontrols2 > theme installs into qt's qqc2 If you mean $QTDIR, that's not my case. The plugin is found via QML2_IMPORT_PATH I suppose. > , to install also an org.kde.desktop > symlink in QtQuickControls1 that just points to "Desktop" (note that > style is not in the kirigami repository, kirigami has themes with the > same name because it's an extension on top of qtquickcontrols2) That sounds good, if it can be done. > > I enabled BUILD_EXAMPLES and got a nice example "kirigami2gallery" built > > as a result, but why is it under the android subdirectory? > > It has some android specific things, like providing a manifest.xml and > some optional qtandroidextras usage for integration when compiled > there, but it's intended to be multiplatform, so may make sesie to > enable it. Then I don't think it should be under an android subdir. A multiplatform app with extra stuff for android integration is still multiplatform in the first place. > talking about examples, do you think is better to build them with a > flag on the top cmake as is now, or provide a separate standalone > cmake file under examples/ ? Much better the way you did it, it's how I see it done in most other frameworks. It makes it easy to enable the building of examples once and for all in kdesrc-buildrc for instance, to make sure they keep compiling and so that they are available for testing. In fact, I wonder if the CI shouldn't set BUILD_EXAMPLES=ON in all frameworks that have that option... (4 currently, 5 with kirigami). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
D5784: Add support for FreeBSD in FSUtils::getDirectoryFileSystem().
adridg added reviewers: kfunk, poboiko. adridg added a comment. Add reviewers who have commented, or who have committed to baloo recently. REPOSITORY R293 Baloo REVISION DETAIL https://phabricator.kde.org/D5784 To: tcberner, #freebsd, kfunk, poboiko Cc: adridg, kfunk, #frameworks
D5784: Add support for FreeBSD in FSUtils::getDirectoryFileSystem().
adridg added a comment. So this patch looks ready to land to me: it simplifies the code, defers fstype-detection to QStorageInfo (for FreeBSD, we should fix the original issue there), and is otherwise non-intrusive. REPOSITORY R293 Baloo REVISION DETAIL https://phabricator.kde.org/D5784 To: tcberner, #freebsd Cc: adridg, kfunk, #frameworks
D5799: Rebase Less syntax highlighting on SCSS one
gszymaszek updated this revision to Diff 15814. gszymaszek added a comment. Added a test file (`autotests/input/highlight.less`). REPOSITORY R216 Syntax Highlighting CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D5799?vs=14376&id=15814 REVISION DETAIL https://phabricator.kde.org/D5799 AFFECTED FILES autotests/input/highlight.less data/syntax/less.xml To: gszymaszek, #framework_syntax_hightlighting Cc: dhaumann, #frameworks, cullmann, vkrause
Re: Kirigami in Frameworks
whops, forgot cc to kde-frameworks, resending On Sat, Jun 24, 2017 at 10:58 AM, David Faure wrote: > On lundi 5 juin 2017 14:42:47 CEST Marco Martin wrote: >> Hi all, >> The Kirigami component set always was targeted to be eventually released as >> a framework, ideally tier 1. since a framework must depend at most from 2 >> Qt releases before the current one, it couldn't be released there yet. Now >> that Qt 5.9 is released > > Given the LTS nature of Qt 5.6 I'd like to keep 5.6 as a base requirement for the > other frameworks for a bit longer if possible, but this doesn't prevent kirigami > from requiring Qt 5.7. > This Qt version difference creates an issue for the CI though, as can be > seen at https://build.kde.org/job/kirigami%20master%20stable-kf5-qt5/ so it could be released as a framework anyways, good If it helps, I could even let it build under 5.6, as everything that depends on 5.7 are qml files, which is a runtime dependency (on a 5.6 system would just install a bunch of dead code in form of qml files) Alternatively, there is still an old branch around that works on Qt 5.6, is pretty much dead, but we still do a bugfix in there every now and then, that one could be built on the 5.6 version of ci >> It strictly depends just from Qt stuff, so should be tier 1 (at runtime it >> can use optional styles that use features from Plasma, tough not having >> plasma installed doesn't touch its functionality in any part, if this ends >> up being a problem, i can move that style into plasma-integration) > > I just cleaned up the toplevel CMakeLists.txt a bit, but I found an issue there: oh, thanks you > it checks for KF5Declarative_FOUND but doesn't do a find_package for that component, so this looks pretty useless. > Since DESKTOP_ENABLED is on by default, what's the point of that if(KF5Declarative_FOUND AND THEME STREQUAL "System") ? uh, leftover, both checks on THEME can be removed safely as DESKTOP_ENABLED and PLASMA_ENABLED install stuff that has more dependencies (always runtime tough and just for the looks, never new api/functionality) is it ok leaving it there built conditionally (easier to maintain) or should be splitted in another repo? > I noticed that DESKTOP_ENABLED installs a file called styles/org.kde.desktop, > which matches a runtime error I've seen for some time now, e.g. at QtCreator startup: > QtCreator(12888)/default QQuickControlSettings1::QQuickControlSettings1: WARNING: Cannot find style "org.kde.desktop" - fallback: "/d/qt/5/kde/build/qtbase/qml/QtQuick/Controls/Styles/Desktop" basically kirigami has a style that is called org.kde.desktop for desktop systems, that matches the style we did for QtQuickControls2 for desktop systems as well, as Qt is not interested to do a desktop specific style for qtquickcontrols2 themselves, however, the environment variable to set the style of both qtquickcontrols1 and 2 style is QT_QUICK_CONTROLS_STYLE, which we set in startkde the default style for QtQuickControlsStyle1 is "Desktop" we could have called this style "Desktop" as well so all would have aligned nicely, but that could be quite dangerous, as Qt coulddecide any moment that they indeed want to do a style called "Desktop" for qqc2, at which point it would conflict, so having the org.kde prefix was the safe route. QtQuickControls1 at this moment doesn't find org.kde.desktop, so just falls back to its default "Desktop" and everything keeps working as expected. One way to silence this could be when the qtquickcontrols2 theme installs into qt's qqc2, to install also an org.kde.desktop symlink in QtQuickControls1 that just points to "Desktop" (note that style is not in the kirigami repository, kirigami has themes with the same name because it's an extension on top of qtquickcontrols2) > I enabled BUILD_EXAMPLES and got a nice example "kirigami2gallery" built as a result, but why is it under the android subdirectory? It has some android specific things, like providing a manifest.xml and some optional qtandroidextras usage for integration when compiled there, but it's intended to be multiplatform, so may make sesie to enable it. talking about examples, do you think is better to build them with a flag on the top cmake as is now, or provide a separate standalone cmake file under examples/ ? -- Marco Martin
Re: Kirigami in Frameworks
On Sat, Jun 24, 2017 at 8:58 PM, David Faure wrote: > On lundi 5 juin 2017 14:42:47 CEST Marco Martin wrote: >> Hi all, >> The Kirigami component set always was targeted to be eventually released as >> a framework, ideally tier 1. since a framework must depend at most from 2 >> Qt releases before the current one, it couldn't be released there yet. Now >> that Qt 5.9 is released > > Given the LTS nature of Qt 5.6 I'd like to keep 5.6 as a base requirement for > the > other frameworks for a bit longer if possible, but this doesn't prevent > kirigami > from requiring Qt 5.7. > This Qt version difference creates an issue for the CI though, as can be > seen at https://build.kde.org/job/kirigami%20master%20stable-kf5-qt5/ Please check the new CI at https://build-sandbox.kde.org/ for the current state of affairs. As the requirements around Qt 4 and some other things have now been sorted I intend to switch it over to become production in the next 24 hours. > >> i would like to propose to move Kirigami in >> frameworks, to be relased in the main release cycle, and stop standalone >> releases from extragear. >> >> It strictly depends just from Qt stuff, so should be tier 1 (at runtime it >> can use optional styles that use features from Plasma, tough not having >> plasma installed doesn't touch its functionality in any part, if this ends >> up being a problem, i can move that style into plasma-integration) > > I just cleaned up the toplevel CMakeLists.txt a bit, but I found an issue > there: > it checks for KF5Declarative_FOUND but doesn't do a find_package for that > component, so this looks pretty useless. > Since DESKTOP_ENABLED is on by default, what's the point of that > if(KF5Declarative_FOUND AND THEME STREQUAL "System") ? > > I noticed that DESKTOP_ENABLED installs a file called styles/org.kde.desktop, > which matches a runtime error I've seen for some time now, e.g. at QtCreator > startup: > QtCreator(12888)/default QQuickControlSettings1::QQuickControlSettings1: > WARNING: Cannot find style "org.kde.desktop" - fallback: > "/d/qt/5/kde/build/qtbase/qml/QtQuick/Controls/Styles/Desktop" > > I enabled BUILD_EXAMPLES and got a nice example "kirigami2gallery" built as a > result, but why is it under the android subdirectory? > (The good thing about this example is now I finally have an idea what > kirigamy is about. The name doesn't really say much ;)) > Cheers, Ben > -- > David Faure, fa...@kde.org, http://www.davidfaure.fr > Working on KDE Frameworks 5 >
D5111: Provide demo/preview for checkable menu items
rjvbb retitled this revision from "Provide demo/preview for checkable menu items and colour scheme comparison" to "Provide demo/preview for checkable menu items". rjvbb edited the summary of this revision. rjvbb edited the test plan for this revision. rjvbb set the repository for this revision to R113 Oxygen Theme. REPOSITORY R113 Oxygen Theme REVISION DETAIL https://phabricator.kde.org/D5111 To: rjvbb, hpereiradacosta, jriddell, zhigalin, anthonyfieroni Cc: ltoscano, kde-mac, #frameworks
D5111: Provide demo/preview for checkable menu items and colour scheme comparison
rjvbb updated this revision to Diff 15812. rjvbb added a comment. Updated for 5.10.2+ CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D5111?vs=12788&id=15812 REVISION DETAIL https://phabricator.kde.org/D5111 AFFECTED FILES kstyle/demo/main.cpp kstyle/demo/oxygendemodialog.cpp kstyle/demo/oxygendemodialog.h kstyle/demo/oxygenmdidemowidget.cpp To: rjvbb, hpereiradacosta, jriddell, zhigalin, anthonyfieroni Cc: ltoscano, kde-mac, #frameworks
Re: Kirigami in Frameworks
On lundi 5 juin 2017 14:42:47 CEST Marco Martin wrote: > Hi all, > The Kirigami component set always was targeted to be eventually released as > a framework, ideally tier 1. since a framework must depend at most from 2 > Qt releases before the current one, it couldn't be released there yet. Now > that Qt 5.9 is released Given the LTS nature of Qt 5.6 I'd like to keep 5.6 as a base requirement for the other frameworks for a bit longer if possible, but this doesn't prevent kirigami from requiring Qt 5.7. This Qt version difference creates an issue for the CI though, as can be seen at https://build.kde.org/job/kirigami%20master%20stable-kf5-qt5/ > i would like to propose to move Kirigami in > frameworks, to be relased in the main release cycle, and stop standalone > releases from extragear. > > It strictly depends just from Qt stuff, so should be tier 1 (at runtime it > can use optional styles that use features from Plasma, tough not having > plasma installed doesn't touch its functionality in any part, if this ends > up being a problem, i can move that style into plasma-integration) I just cleaned up the toplevel CMakeLists.txt a bit, but I found an issue there: it checks for KF5Declarative_FOUND but doesn't do a find_package for that component, so this looks pretty useless. Since DESKTOP_ENABLED is on by default, what's the point of that if(KF5Declarative_FOUND AND THEME STREQUAL "System") ? I noticed that DESKTOP_ENABLED installs a file called styles/org.kde.desktop, which matches a runtime error I've seen for some time now, e.g. at QtCreator startup: QtCreator(12888)/default QQuickControlSettings1::QQuickControlSettings1: WARNING: Cannot find style "org.kde.desktop" - fallback: "/d/qt/5/kde/build/qtbase/qml/QtQuick/Controls/Styles/Desktop" I enabled BUILD_EXAMPLES and got a nice example "kirigami2gallery" built as a result, but why is it under the android subdirectory? (The good thing about this example is now I finally have an idea what kirigamy is about. The name doesn't really say much ;)) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
D6202: Expand apidox of KJobWidget::setWindow()
dfaure accepted this revision. This revision is now accepted and ready to land. REPOSITORY R288 KJobWidgets BRANCH master REVISION DETAIL https://phabricator.kde.org/D6202 To: elvisangelaccio, #frameworks, dfaure
