KDE CI: Frameworks baloo kf5-qt5 XenialQt5.7 - Build # 39 - Still Unstable!
BUILD UNSTABLE Build URL https://build.kde.org/job/Frameworks%20baloo%20kf5-qt5%20XenialQt5.7/39/ Project: Frameworks baloo kf5-qt5 XenialQt5.7 Date of build: Sat, 11 Nov 2017 05:32:29 + Build duration: 6 min 11 sec and counting JUnit Tests Name: (root) Failed: 1 test(s), Passed: 38 test(s), Skipped: 0 test(s), Total: 39 test(s)Failed: TestSuite.kinotifytest Cobertura Report Project Coverage Summary Name PackagesFilesClassesLinesConditionalsCobertura Coverage Report100% (12/12)77% (111/144)77% (111/144)73% (5035/6932)50% (2611/5194)Coverage Breakdown by Package Name FilesClassesLinesConditionalsautotests.benchmarks100% (2/2)100% (2/2)100% (42/42)89% (16/18)autotests.integration100% (3/3)100% (3/3)95% (242/255)64% (140/220)autotests.unit.codecs100% (3/3)100% (3/3)100% (40/40)57% (25/44)autotests.unit.engine100% (17/17)100% (17/17)100% (736/736)53% (390/740)autotests.unit.file100% (11/11)100% (11/11)97% (788/809)51% (438/864)autotests.unit.lib100% (6/6)100% (6/6)97% (315/326)52% (156/302)src.codecs100% (5/5)100% (5/5)87% (120/138)76% (32/42)src.engine97% (38/39)97% (38/39)79% (1603/2038)58% (794/1379)src.file39% (17/44)39% (17/44)45% (678/1506)38% (374/980)src.file.extractor100% (2/2)100% (2/2)69% (20/29)58% (7/12)src.file.extractor.autotests100% (1/1)100% (1/1)100% (22/22)61% (11/18)src.lib55% (6/11)55% (6/11)43% (429/991)40% (228/575)
D8461: Remove unused config.h.cmake entries
This revision was automatically updated to reflect the committed changes. Closed by commit R293:d636fdc569ea: Remove unused config.h.cmake entries (authored by davidk). REPOSITORY R293 Baloo CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D8461?vs=22171&id=22172 REVISION DETAIL https://phabricator.kde.org/D8461 AFFECTED FILES ConfigureChecks.cmake config.h.cmake To: davidk, dfaure Cc: dfaure, #frameworks
D8461: Remove unused config.h.cmake entries
davidk updated this revision to Diff 22171. davidk added a comment. Improve commit message REPOSITORY R293 Baloo CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D8461?vs=21277&id=22171 BRANCH cleanup REVISION DETAIL https://phabricator.kde.org/D8461 AFFECTED FILES ConfigureChecks.cmake config.h.cmake To: davidk, dfaure Cc: dfaure, #frameworks
D8330: Open files in TagLib extractor readonly
This revision was automatically updated to reflect the committed changes. Closed by commit R286:098d62874591: Open files in TagLib extractor readonly (authored by davidk). REPOSITORY R286 KFileMetaData CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D8330?vs=20855&id=22170 REVISION DETAIL https://phabricator.kde.org/D8330 AFFECTED FILES src/extractors/taglibextractor.cpp To: davidk, #frameworks, vhanda, cgiboudeaux, dfaure, mgallien Cc: mgallien, ngraham, #frameworks
D8728: Install mimetype definitions for kcfg/kcfgc/ui.rc/knotify & qrc files
kossebau added inline comments. INLINE COMMENTS > kossebau wrote in kde5.xml:3647 > This one surely should be also added to shared-mime-info, once proposed name > and details have been checked. > > Anyone up for that task, ideally someone who could run this also across Qt > contributor eyes? > Surprised that one has not yet been added there. See also https://bugreports.qt.io/browse/QTBUG-64435 REPOSITORY R244 KCoreAddons REVISION DETAIL https://phabricator.kde.org/D8728 To: kossebau, #frameworks Cc: ngraham
Re: Making Purpose part of KF5
On Fri, Nov 10, 2017 at 1:20 PM, Hartmut Goebel wrote: > Am 10.11.2017 um 12:50 schrieb Aleix Pol: >> I share the concern in fact, part of the reason why I didn't push it >> earlier was to be able to have it proper tier2. My reasoning for >> leaving it as this is that it just adds an extra step users will have >> to take to install the plugins and it's not a very useful one (to pull >> the plugins). Without plugins, purpose is useless. > > This means: purpose is the framework and ought to be in"frameworks". > Maybe it should be called "purpose-framework" to emphasis this. > > The plugins have more dependencies and should not go into the framework, > though. > > If purpose would introduce higher level dependencies, how should this be > build then? You'll end up with cyclic dependencies, which are a horror > to build. > > Please move the plugins into a separate repository or at least make them > to be build *completely* separate (like a subproject.) The fact that there's plugins in the repository now doesn't mean by far that there can't be plugins inside. For example note that kio has some ioslaves in src/ioslaves and I'd say that's perfectly fine. Aleix
Re: Making Purpose part of KF5
Am 10.11.2017 um 12:50 schrieb Aleix Pol: > I share the concern in fact, part of the reason why I didn't push it > earlier was to be able to have it proper tier2. My reasoning for > leaving it as this is that it just adds an extra step users will have > to take to install the plugins and it's not a very useful one (to pull > the plugins). Without plugins, purpose is useless. This means: purpose is the framework and ought to be in"frameworks". Maybe it should be called "purpose-framework" to emphasis this. The plugins have more dependencies and should not go into the framework, though. If purpose would introduce higher level dependencies, how should this be build then? You'll end up with cyclic dependencies, which are a horror to build. Please move the plugins into a separate repository or at least make them to be build *completely* separate (like a subproject.) -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Making Purpose part of KF5
On Fri, Nov 10, 2017 at 1:16 AM, David Edmundson wrote: > > > On Thu, Nov 9, 2017 at 11:45 PM, Aleix Pol wrote: >> >> On Thu, Nov 9, 2017 at 7:35 PM, David Edmundson >> wrote: >> > I think having src/plugins in the framework will cause problems. >> >> Can you please elaborate? >> > You'll have to have every dependency possible, and then no-one will use the > lib because of that. > >> >> I'm not excited about having all the plugins inside TBH, but then I >> don't see another way around that isn't having a purpose-plugins >> repository (or a purpose-nextcloud, purpose-kdeconnect, etc à la ktp >> ;-) ). > > > So like kio & kio-extras? I don't think that's a huge problem. My thinking is that it should be good enough to make the dependencies of the plugins optional rather than creating a whole separate repository. I share the concern in fact, part of the reason why I didn't push it earlier was to be able to have it proper tier2. My reasoning for leaving it as this is that it just adds an extra step users will have to take to install the plugins and it's not a very useful one (to pull the plugins). Without plugins, purpose is useless. > >> >> >> > >> > Also the docs need a thorough cleanup >> > >> > "To import it from QML, import >> > import org.kde.people 1.0" >> >> Fixed. *rolls eyes* >> >> > and the c++ headers need some too. >> >> If you know other issues tell me and I'll fix it, I'm not sure what you > > > I opened a few header files, half the methods had some docs, the other half > did not. > I'm not going to list them. Oh, api documentation, I guess, will add to my to do list. > --- > > One question about the way the whole thing fundamentally works: > We're moving towards a world where apps are sandboxed, binary plugins aren't > going to be a thing we can really use. > > As one of our resident flatpak experts, is this future proof? > If not, can we expand on the whole external process concept so that a job > can be proxied through a portal? It can, it's not implemented. At the moment we already have the concept of executing the plugins out of process, so making an implementation that would move this outside of the sandbox is easily doable. But then we are requiring the host system to have Purpose installed, and that's a bit odd. There's nothing fundamentally wrong in shipping Purpose and plugins within the sandbox, in fact it's what we do nowadays for many things such as KIO and I don't see us changing this in the foreseeable future. One thing I was thinking of doing was to actually expose some API in the QuickShare plasmoid so that when we share something it happens there, thinking of a dbus interface that can optionally be used. This would fit very well with flatpak/snap story but still be a mere fallback. The big advantage being that it would allow us to not have every plugin on earth present in the container and use the systems', although we will always need to have a fallback for users without quickshare or even plasma. HTH, Aleix
D8691: add some metadata
This revision was automatically updated to reflect the committed changes. Closed by commit R296:ae8d97bb5274: add some metadata (authored by mart). REPOSITORY R296 KDeclarative CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D8691?vs=22022&id=22141 REVISION DETAIL https://phabricator.kde.org/D8691 AFFECTED FILES src/quickaddons/configmodule.cpp src/quickaddons/configmodule.h To: mart, #plasma, davidedmundson Cc: plasma-devel, #frameworks, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D8662: Validate that for all attributes an itemData exists
vkrause accepted this revision. This revision is now accepted and ready to land. REPOSITORY R216 Syntax Highlighting BRANCH master REVISION DETAIL https://phabricator.kde.org/D8662 To: dhaumann, vkrause, cullmann Cc: #frameworks
D8546: Add Aztec code generator
vkrause added inline comments. INLINE COMMENTS > svuorela wrote in aztec-compact-data-0011.png:1 > For all these images, are this the only valid encoding for the relevant data, > or are there enough extra data in aztec codes that a valid set of data can be > encoded in multiple ways ? There are two kinds of test images here, those that test just the rendering code and those that test the full encoding too. The first ones are not valid codes but are unique. The latter are valid but unfortunately all but unique. There's multiple valid ways to encode input text into the bit stream, and you can select how much error correction you want to have. REPOSITORY R280 Prison REVISION DETAIL https://phabricator.kde.org/D8546 To: vkrause, #frameworks, svuorela, dfaure Cc: dfaure, #frameworks
