KDE CI: Frameworks baloo kf5-qt5 XenialQt5.7 - Build # 39 - Still Unstable!

[CI System]

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

[David Kahles]

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=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

[David Kahles]

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=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

[David Kahles]

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=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

[Friedrich W . H . Kossebau]

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

CMake 3.10.0-rc5 is now ready for testing

[Robert Maynard]

I am proud to announce the fifth CMake 3.10 release candidate.
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.10

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.10/release/3.10.html

Some of the more significant changes in CMake 3.10 are:

* The flang Fortran compiler is now supported, with compiler id
  "Flang".

* Support for the MSVC ARM64 architecture was added. Visual Studio
  2017 Update 4 and above offer an ARM64 toolchain.

* The "include_guard()" command was introduced to allow guarding
  CMake scripts from being included more than once. The command
  supports "DIRECTORY" and "GLOBAL" options to adjust the
  corresponding include guard scope. If no options given, include
  guard is similar to basic variable-based check.

* "FindMPI" received a major overhaul. It now features language specific
  components, better Fortran support, and support for statically linked
  MPI implementations.

* A "FindOpenACC" module was added to detect compiler support for
  OpenACC.  Currently only supports PGI, GNU and Cray compilers.

* The "FindOpenGL" module underwent numerous improvements. It has gained
  support for GLVND and EGL on Linux. It now has import targets that
  separate the OpenGL library and OpenGL contexts.

* The "GoogleTest" module gained a new command
  "gtest_discover_tests()" implementing dynamic (build-time) test
  discovery.

* When using "AUTOMOC" or "AUTOUIC", source files that are
  "GENERATED" will be processed as well. They were ignored by
  "AUTOMOC" and "AUTOUIC" in earlier releases. See policy "CMP0071".

* A "CTEST_LABELS_FOR_SUBPROJECTS" CTest module variable and CTest
  script variable were added to specify a list of labels that should
  be treated as subprojects by CDash. To use this value in both the
  CTest module and the ctest command line Dashboard Client mode (e.g.
  "ctest -S") set it in the "CTestConfig.cmake" config file.

* CPack gained a "FREEBSD" generator for FreeBSD "pkg(8)",
  configured by the "CPackFreeBSD" module.

* The CPack "DEB" generator, configured by the "CPackDeb" module,
  was enabled on Windows.  While not fully featured (due to the lack
  of external UNIX tools) this will allow building basic cross-
  platform Debian packages.

* The "cmake(1)" "-E" mode gained support for "sha1sum",
  "sha224sum", "sha256sum", "sha384sum", and "sha512sum".

* The "file(GENERATE)" command now interprets relative paths given
  to its "OUTPUT" and "INPUT" arguments with respect to the caller's
  current binary and source directories, respectively. See policy
  "CMP0070".

CMake 3.10 Release Notes


Changes made since CMake 3.9 include the following.


New Features



Platforms
-

* The flang Fortran compiler is now supported, with compiler id
  "Flang".

* A new minimal platform file for "Midipix" was added.

* Support for the MSVC ARM64 architecture was added. Visual Studio
  2017 Update 4 and above offer an ARM64 toolchain.

* Support for the IAR ARM Compiler was improved.


Generators
--

* The Makefile Generators and the "Ninja" generator learned to add
  compiler launcher tools like ccache along with the compiler for the
  "CUDA" language ("C" and "CXX" were supported previously).  See the
  "CMAKE__COMPILER_LAUNCHER" variable and
  "_COMPILER_LAUNCHER" target property for details.

* The "CodeBlocks" extra generator learned to optionally exclude
  files from outside the project root directory from the generated
  project. See the "CMAKE_CODEBLOCKS_EXCLUDE_EXTERNAL_FILES" variable.


Commands


* The "cmake_host_system_information()" command learned more keys to
  get information about the processor capabilities and the host OS
  version.

* The "configure_file()" command learned to support indented "#
  cmakedefine" and "#  cmakedefine01". Spaces and/or tabs between the
  "#" character and the "cmakedefine"/"cmakedefine01" words are now
  understood and preserved in the output.

* The "execute_process()" command gained a "RESULTS_VARIABLE" option
  to collect a list of results from all children in a pipeline of
  processes when multiple "COMMAND" arguments are given.

* The "include_guard()" command was introduced to allow guarding
  CMake scripts from being included more than once. The command
  supports "DIRECTORY" and "GLOBAL" options to adjust the
  corresponding include guard scope. If no options given, include
  guard is similar to basic variable-based check.

* The "string()" command learned a new "PREPEND" subcommand.

* The "string(TIMESTAMP)" command now supports "%A" for full weekday
  name and "%B" for full month name.


Variables
-

* A "CMAKE_DIRECTORY_LABELS" variable was added to specify labels
  for all tests in a directory.


Properties
--

* A "_CPPCHECK" target property and supporting
  "CMAKE__CPPCHECK" variable were introduced to tell the
  Makefile Generators and the "Ninja" 

Significant CI Maintenance

[Ben Cooksley]

Hi all,

As some of you will know, we're currently unable to build our Fedora
image on the CI system, and have effectively been unable to do so for
some time. At this stage I do not see a permanent resolution to the
issue arising soon.

In order to restore our ability to make changes to the system again,
i'm now in the process of removing all the Fedora builds and replacing
them with equivalent ones using the SUSE image, which is already used
for Extragear and Plasma builds.

As such, you may see greater than normal levels of noise from the CI
system surrounding these jobs while the transition is made. Once the
builds are fully operational under the SUSE builds, all of the Fedora
builds will be removed.

My apologies for the inconvenience, particularly given an Applications
release has just taken place.

Regards,
Ben Cooksley
KDE Sysadmin

Significant CI Maintenance

[Ben Cooksley]

Hi all,

As some of you will know, we're currently unable to build our Fedora
image on the CI system, and have effectively been unable to do so for
some time. At this stage I do not see a permanent resolution to the
issue arising soon.

In order to restore our ability to make changes to the system again,
i'm now in the process of removing all the Fedora builds and replacing
them with equivalent ones using the SUSE image, which is already used
for Extragear and Plasma builds.

As such, you may see greater than normal levels of noise from the CI
system surrounding these jobs while the transition is made. Once the
builds are fully operational under the SUSE builds, all of the Fedora
builds will be removed.

My apologies for the inconvenience, particularly given an Applications
release has just taken place.

Regards,
Ben Cooksley
KDE Sysadmin

Re: Making Purpose part of KF5

[Aleix Pol]

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

[Hartmut Goebel]

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 |

[ANNOUNCE] CMake 3.9.6 available for download

[Robert Maynard]

We are pleased to announce that CMake 3.9.6 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-
Changes in 3.9.6 since 3.9.5:

Brad King (1):
  CMake 3.9.6

Christian Pfeiffer (1):
  Restore exclusion of "gcc_eh" from implicit link libraries

Re: Making Purpose part of KF5

[Aleix Pol]

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

Re: Making Purpose part of KF5

[Aleix Pol]

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

[Marco Martin]

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=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

[Volker Krause]

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

[Volker Krause]

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