Re: kwalletd about to be switched from kde-runtime to kwallet-framework

[Valentin Rusu]

On 01/13/2014 10:05 PM, Valentin Rusu wrote:
> On 01/12/2014 07:59 PM, Valentin Rusu wrote:
>> Hello,
>>
>> Please be informed that I successfully imported the git history of
>> kwalletd from kde-runtime to kwallet-framework, the I ported it to KF5.
>> The code is ready to be pushed, but there are 430 commits waiting on my
>> local copy. I filed a sysadmin ticket and as soon as it gets handled,
>> I'll push it.
> 
> The push actually took place. kwalletd is now in kwallet-frameworks.
> 
> However, it won't build, sorry. It was building fine on my system, but
> perhaps I didn't catch some latest changes with the build system. Right
> now I'm doing a clean build of frameworks hoping that will help me spot
> where the problem is.

OK, I now understand what's happening. It's a dependency (order of
build) problem, as when performing frameworks fresh build,
kwallet-framework fails then when rebuilding starting with
kwallet-frameworks, it works. I'll fix that later, I must now leave.
Meanwhile, I'd like to ask what's the preferred method to fixing this
kind of dependency problems with frameworks?






signature.asc
Description: OpenPGP digital signature
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Integrating kf5dot and kapidox

[Aurélien Gâteau]

On Mon, Jan 13, 2014, at 14:34, Alex Merry wrote:
> On 13/01/14 21:36, Aurélien Gâteau wrote:
> > Second, api.kde.org deployment. kf5dot-prepare needs to be able to run
> > CMake on the source code. @Allen: is it possible to do this on
> > api.kde.org?
> 
> kgenapidox could potentially extract info from the build dir,
> incidentally.
> 
> In particular, the generated version files could be used to get a
> project version and the build dir could be added to the INPUT
> directories to parse generated files.
> 
> kgenframeworksapidox could also use the dependency information to
> properly order the frameworks so it doesn't have to do any rebuilding
> (currently, it builds each tier3 and tier4 framework's documentation
> twice).
> 
> Alex
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 115005: Install forwarding headers for plain knewstuff3 headers

[Friedrich W. H. Kossebau]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115005/
---

Review request for KDE Frameworks, David Faure and Jeremy Whiting.


Repository: kde4support


Description
---

To be seen combined with https://git.reviewboard.kde.org/r/114988/

Installation prefix was changed from knewtuff3/ to kns3/
Also remove no longer needed CamelCase forwarding headers, because
they are installed again with the old prefix from the KNewStuff module

See also discussion 
http://lists.kde.org/?l=kde-frameworks-devel&m=138963692808275&w=2


Diffs
-

  src/CMakeLists.txt 241e0c6 
  src/includes/CMakeLists.txt 8781a9a 
  src/includes/KNS3/DownloadDialog dd7ef3a 
  src/includes/KNS3/Entry cb98675 
  src/includes/KNS3/KNewStuffAction 48936eb 
  src/includes/KNS3/KNewStuffButton aa033e1 
  src/knewstuff3/downloaddialog.h PRE-CREATION 
  src/knewstuff3/downloadmanager.h PRE-CREATION 
  src/knewstuff3/downloadwidget.h PRE-CREATION 
  src/knewstuff3/entry.h PRE-CREATION 
  src/knewstuff3/knewstuffaction.h PRE-CREATION 
  src/knewstuff3/knewstuffbutton.h PRE-CREATION 
  src/knewstuff3/uploaddialog.h PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/115005/diff/


Testing
---


Thanks,

Friedrich W. H. Kossebau

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 114988: Fix PREFIX parameter to ecm_generate_headers to match namespace KNS3

[Friedrich W. H. Kossebau]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/114988/
---

(Updated Jan. 13, 2014, 11:39 p.m.)


Review request for KDE Frameworks, Aleix Pol Gonzalez, David Faure, and Jeremy 
Whiting.


Changes
---

Improvements as discussed.


Repository: knewstuff


Description (updated)
---

To be seen combined with https://git.reviewboard.kde.org/r/115005/

Currently the KNewStuff CamelCase forwarding headers are installed in 
[...]/include/KF5/KNewStuff3/knewstuff3
Which seems wrong, at least does not follow the pattern seen with the other 
namespaced modules. And breaks all existing #includes if the build does not use 
KDE4Support with its variants of the CamelCase forwarding headers.

Attached patch changes the PREFIX parameter to ecm_generate_headers from 
knewstuff3 to KNS3, so that the prefix matches the namespace of the classes in 
the module.
This means also a change of the prefix for the normal headers, but as discussed 
in http://lists.kde.org/?l=kde-frameworks-devel&m=138963692808275&w=2 that is 
preferred over the old solution. According new backward kde4-style support is 
proposed in the RR linked above.

Patch also
* removes knewstuffbutton.h, now installed from kdesupport
* removes no longer needed utility include dir cmake code (this could be found 
also in a few other frameworks, so there will be follow-up patches)


Diffs (updated)
-

  src/CMakeLists.txt 05cd500 
  src/knewstuffbutton.h 931a465 

Diff: https://git.reviewboard.kde.org/r/114988/diff/


Testing
---

Applied and run make install: CamelCase includes are installed in 
[...]/include/KF5/KNewStuff3/KNS3 directory, code which #includes KNS3/* 
without KDE4Support builds.


Thanks,

Friedrich W. H. Kossebau

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Build failed in Jenkins: kwallet-framework_master_qt5 #15

[KDE CI System]

See 

Changes:

[kde] Attempt fixing build

--
Started by remote host 127.0.0.1 with note: Triggered by commit
Building remotely on LinuxSlave - 3 in workspace 

Running Prebuild steps
[kwallet-framework_master_qt5] $ /bin/sh -xe /tmp/hudson5385459683081112437.sh
+ /home/jenkins/scripts/setup-env.sh

Preparing to perform KDE Continuous Integration build
== Setting Up Sources

>From git://anongit.kde.org/kwallet-framework
   b06a3fb..fe919a5  master -> origin/master
Branch jenkins set up to track remote branch master from origin.

== Cleaning Source Tree

HEAD is now at b06a3fb Fix build when standalone
Removing build/
Success build forhudson.tasks.Shell@23056bf9
Fetching changes from the remote Git repository
Fetching upstream changes from git://anongit.kde.org/kwallet-framework
Checking out Revision fe919a5591992dd8f362f2541e394f60f064cf6d 
(refs/heads/jenkins)
Run condition [File exists] enabling prebuild for step [Publish JUnit test 
result report]
Run condition [File exists] enabling prebuild for step [Publish Cppcheck 
results]
[kwallet-framework_master_qt5] $ /bin/sh -xe /tmp/hudson715124514046687854.sh
+ /home/jenkins/scripts/execute-job.sh

KDE Continuous Integration Build
== Building Project: kwallet-framework - Branch master
== Build Dependencies:
 kwindowsystem - Branch master
 qt5 - Branch stable
 extra-cmake-modules - Branch master
 cmake - Branch master
 kconfig - Branch master

== Applying Patches
=== No patches to apply

== Syncing Dependencies from Master Server


== Configuring Build

-- The C compiler identification is GNU 4.7.2
-- The CXX compiler identification is GNU 4.7.2
-- Check for working C compiler: /home/jenkins/bin/cc
-- Check for working C compiler: /home/jenkins/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /home/jenkins/bin/c++
-- Check for working CXX compiler: /home/jenkins/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Performing Test __KDE_HAVE_W_OVERLOADED_VIRTUAL
-- Performing Test __KDE_HAVE_W_OVERLOADED_VIRTUAL - Success
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success
CMake Error at src/runtime/kwalletd/CMakeLists.txt:8 (find_package):
  Could not find a package configuration file provided by "KF5" with any of
  the following names:

KF5Config.cmake
kf5-config.cmake

  Add the installation prefix of "KF5" to CMAKE_PREFIX_PATH or set "KF5_DIR"
  to a directory containing one of the above files.  If "KF5" provides a
  separate development package or SDK, be sure it has been installed.


-- Configuring incomplete, errors occurred!
See also 
"
Configure step exited with non-zero code, assuming failure to configure for 
project kwallet-framework.
Build step 'Execute shell' marked build as failure
[File exists] check if file exists [build/JUnitTestResults.xml]
Run condition [File exists] preventing perform for step [Publish JUnit test 
result report]
[File exists] check if file exists [build/cppcheck.xml]
Run condition [File exists] preventing perform for step [Publish Cppcheck 
results]
[WARNINGS] Skipping publisher since build result is FAILURE
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Build failed in Jenkins: kwallet-framework_master_qt5 #14

[KDE CI System]

See 

Changes:

[kde] Fix build when standalone

--
Started by remote host 127.0.0.1 with note: Triggered by commit
Building remotely on LinuxSlave - 3 in workspace 

Running Prebuild steps
[kwallet-framework_master_qt5] $ /bin/sh -xe /tmp/hudson99185482401044386.sh
+ /home/jenkins/scripts/setup-env.sh

Preparing to perform KDE Continuous Integration build
== Setting Up Sources

>From git://anongit.kde.org/kwallet-framework
   5143766..b06a3fb  master -> origin/master
Branch jenkins set up to track remote branch master from origin.

== Cleaning Source Tree

HEAD is now at 5143766 Fix find_package lines
Removing build/
Success build forhudson.tasks.Shell@23056bf9
Fetching changes from the remote Git repository
Fetching upstream changes from git://anongit.kde.org/kwallet-framework
Checking out Revision b06a3fbb72d218c089b8148dc54f76acb6f71b82 
(refs/heads/jenkins)
Run condition [File exists] enabling prebuild for step [Publish JUnit test 
result report]
Run condition [File exists] enabling prebuild for step [Publish Cppcheck 
results]
[kwallet-framework_master_qt5] $ /bin/sh -xe /tmp/hudson5829040256668921969.sh
+ /home/jenkins/scripts/execute-job.sh

KDE Continuous Integration Build
== Building Project: kwallet-framework - Branch master
== Build Dependencies:
 kwindowsystem - Branch master
 extra-cmake-modules - Branch master
 qt5 - Branch stable
 kconfig - Branch master
 cmake - Branch master

== Applying Patches
=== No patches to apply

== Syncing Dependencies from Master Server


== Configuring Build

-- The C compiler identification is GNU 4.7.2
-- The CXX compiler identification is GNU 4.7.2
-- Check for working C compiler: /home/jenkins/bin/cc
-- Check for working C compiler: /home/jenkins/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /home/jenkins/bin/c++
-- Check for working CXX compiler: /home/jenkins/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Performing Test __KDE_HAVE_W_OVERLOADED_VIRTUAL
-- Performing Test __KDE_HAVE_W_OVERLOADED_VIRTUAL - Success
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success
CMake Error at src/runtime/kwalletd/CMakeLists.txt:5 (find_package):
  Could not find a package configuration file provided by "KF5" with any of
  the following names:

KF5Config.cmake
kf5-config.cmake

  Add the installation prefix of "KF5" to CMAKE_PREFIX_PATH or set "KF5_DIR"
  to a directory containing one of the above files.  If "KF5" provides a
  separate development package or SDK, be sure it has been installed.


-- Configuring incomplete, errors occurred!
See also 
"
Configure step exited with non-zero code, assuming failure to configure for 
project kwallet-framework.
Build step 'Execute shell' marked build as failure
[File exists] check if file exists [build/JUnitTestResults.xml]
Run condition [File exists] preventing perform for step [Publish JUnit test 
result report]
[File exists] check if file exists [build/cppcheck.xml]
Run condition [File exists] preventing perform for step [Publish Cppcheck 
results]
[WARNINGS] Skipping publisher since build result is FAILURE
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 115004: use KDeclarative namespace for kdeclarative framework classes

[David Edmundson]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115004/#review47353
---

Ship it!


Looks good to me. 

- David Edmundson


On Jan. 13, 2014, 8:02 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115004/
> ---
> 
> (Updated Jan. 13, 2014, 8:02 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> KDeclarative has very generic class names, therefore a bad practiche for 
> public symbols.
> this moves it under KDeclarative:: namespace as discussed in the sprint
> 
> 
> Diffs
> -
> 
>   src/configpropertymap.h aeb41b5 
>   src/configpropertymap.cpp 73e21d8 
>   src/kdeclarative.h 84e8df4 
>   src/kdeclarative.cpp 8aed99c 
>   src/private/kdeclarative_p.h 91e83cc 
>   src/private/kiconprovider.cpp 27eb8d1 
>   src/private/kiconprovider_p.h 3773e0c 
>   src/private/kioaccessmanagerfactory.cpp ea73c45 
>   src/private/kioaccessmanagerfactory_p.h 7f7cc73 
>   src/private/qmlobject_p.h e5b32f8 
>   src/private/rootcontext.cpp 503b430 
>   src/private/rootcontext_p.h 805f7fa 
>   src/qmlobject.h 5028559 
>   src/qmlobject.cpp d00ff40 
>   tests/kdeclarativetest.cpp dd34d88 
> 
> Diff: https://git.reviewboard.kde.org/r/115004/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Integrating kf5dot and kapidox

[Alex Merry]

On 13/01/14 21:36, Aurélien Gâteau wrote:
> Second, api.kde.org deployment. kf5dot-prepare needs to be able to run
> CMake on the source code. @Allen: is it possible to do this on
> api.kde.org?

kgenapidox could potentially extract info from the build dir, incidentally.

In particular, the generated version files could be used to get a
project version and the build dir could be added to the INPUT
directories to parse generated files.

kgenframeworksapidox could also use the dependency information to
properly order the frameworks so it doesn't have to do any rebuilding
(currently, it builds each tier3 and tier4 framework's documentation twice).

Alex
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Integrating kf5dot and kapidox

[Aurélien Gâteau]

[Errr... my message got truncated. Let's try again]

Now that kf5dot is (hopefully) mostly feature-complete, I think it is
time to decide how to integrate it in kapidox.

The way kf5dot works is the following:

1. kf5dot-prepare runs CMake on the frameworks source to generate
   Graphviz dot files. It also copies the framework yaml file in the
   output dir.

2. kf5dot-generate parses the dot files and the framework yaml file to
   generate new dot files, which can then be passed to the `dot` tool
   to generate png files.

The flow is thus:

~/src/frameworks/
kauth/
src/
kauth.yaml
CMakeLists.txt
...
kio/
src/
kio.yaml
CMakeLists.txt
...

|
V

kf5dot-prepare ~/src/frameworks ~/dots

|
V

~/dots/
tier1/
...
tier2/
kauth/
kauth.dot
kauth.yaml
...
tier3/
kio/
kio.dot
kio.yaml
...
|
V

kf5dot-generate ~/dots/tier*/*/*.dot --framework kauth \
| dot -Tpng > ~/out/kauth.png

kf5dot-generate ~/dots/tier*/*/*.dot --framework kio \
| dot -Tpng > ~/out/kio.png

kf5dot-generate ~/dots/tier*/*/*.dot \
| tred | dot -Tpng > ~/out/kf5.png

|
V

~/out/
kauth.png
kio.png
kf5.png


# Integration

First, the code. Right now the kf5dot code is in its own repository, I
think it should be moved to kapidox/src/kf5dot, unless someone thinks
it's a bad idea.

Second, api.kde.org deployment. kf5dot-prepare needs to be able to run
CMake on the source code. @Allen: is it possible to do this on
api.kde.org?

Third: inclusion in the generated documentation. I would like to see the
dependency diagram of each framework included in the landing page of its
documentation, and possible the overall KF5 diagram (if we think it is
useful) on the main landing page.

Generating dependency diagrams should not be required however: we should
ensure kgenapidox can be run by developers and framework maintainers on
their local machines, since it reduces the effort needed to maintain
documentation (and it helps preventing any "works only on the production
system" issue).

This means kgenapidox and kgenframeworksapidox should be able to take
advantage of the dependency diagrams if they are available, but should
not fail if they are not.

I think this can be done by adding a --dependency-diagram-dir option to
the scripts, which would point to the dir where all the diagrams are.
kgenapidox should then include the diagram in the HTML page generated
from the README.md of each framework.
Does it make sense to you?

@Alex: is it possible to have a Pystache template for the README.md?

Aurélien
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: kwalletd about to be switched from kde-runtime to kwallet-framework

[Valentin Rusu]

On 01/12/2014 07:59 PM, Valentin Rusu wrote:
> Hello,
> 
> Please be informed that I successfully imported the git history of
> kwalletd from kde-runtime to kwallet-framework, the I ported it to KF5.
> The code is ready to be pushed, but there are 430 commits waiting on my
> local copy. I filed a sysadmin ticket and as soon as it gets handled,
> I'll push it.

The push actually took place. kwalletd is now in kwallet-frameworks.

However, it won't build, sorry. It was building fine on my system, but
perhaps I didn't catch some latest changes with the build system. Right
now I'm doing a clean build of frameworks hoping that will help me spot
where the problem is.





signature.asc
Description: OpenPGP digital signature
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins build is back to stable : ktexteditor_master_qt5 #27

[KDE CI System]

See 

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Build failed in Jenkins: kwallet-framework_master_qt5 #13

[KDE CI System]

See 

Changes:

[kde] Fix build, once again...

--
Started by remote host 127.0.0.1 with note: Triggered by commit
Building remotely on LinuxSlave - 3 in workspace 

Running Prebuild steps
[kwallet-framework_master_qt5] $ /bin/sh -xe /tmp/hudson2777428678423313604.sh
+ /home/jenkins/scripts/setup-env.sh

Preparing to perform KDE Continuous Integration build
== Setting Up Sources

>From git://anongit.kde.org/kwallet-framework
   89d1dad..5143766  master -> origin/master
Branch jenkins set up to track remote branch master from origin.

== Cleaning Source Tree

HEAD is now at 89d1dad Fix build, once again...
Removing build/
Success build forhudson.tasks.Shell@23056bf9
Fetching changes from the remote Git repository
Fetching upstream changes from git://anongit.kde.org/kwallet-framework
Checking out Revision 51437661855312f4ecaa28691c7d0381789bc6d9 
(refs/heads/jenkins)
Run condition [File exists] enabling prebuild for step [Publish JUnit test 
result report]
Run condition [File exists] enabling prebuild for step [Publish Cppcheck 
results]
[kwallet-framework_master_qt5] $ /bin/sh -xe /tmp/hudson7521489361217038150.sh
+ /home/jenkins/scripts/execute-job.sh

KDE Continuous Integration Build
== Building Project: kwallet-framework - Branch master
== Build Dependencies:
 kconfig - Branch master
 qt5 - Branch stable
 kwindowsystem - Branch master
 extra-cmake-modules - Branch master
 cmake - Branch master

== Applying Patches
=== No patches to apply

== Syncing Dependencies from Master Server


== Configuring Build

-- The C compiler identification is GNU 4.7.2
-- The CXX compiler identification is GNU 4.7.2
-- Check for working C compiler: /home/jenkins/bin/cc
-- Check for working C compiler: /home/jenkins/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /home/jenkins/bin/c++
-- Check for working CXX compiler: /home/jenkins/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Performing Test __KDE_HAVE_W_OVERLOADED_VIRTUAL
-- Performing Test __KDE_HAVE_W_OVERLOADED_VIRTUAL - Success
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success
CMake Error at src/runtime/kwalletd/CMakeLists.txt:4 (find_package):
  Could not find a package configuration file provided by "KF5" with any of
  the following names:

KF5Config.cmake
kf5-config.cmake

  Add the installation prefix of "KF5" to CMAKE_PREFIX_PATH or set "KF5_DIR"
  to a directory containing one of the above files.  If "KF5" provides a
  separate development package or SDK, be sure it has been installed.


-- Configuring incomplete, errors occurred!
See also 
"
Configure step exited with non-zero code, assuming failure to configure for 
project kwallet-framework.
Build step 'Execute shell' marked build as failure
[File exists] check if file exists [build/JUnitTestResults.xml]
Run condition [File exists] preventing perform for step [Publish JUnit test 
result report]
[File exists] check if file exists [build/cppcheck.xml]
Run condition [File exists] preventing perform for step [Publish Cppcheck 
results]
[WARNINGS] Skipping publisher since build result is FAILURE
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Build failed in Jenkins: kwallet-framework_master_qt5 #12

[KDE CI System]

See 

Changes:

[kde] Fix build, once again...

--
Started by remote host 127.0.0.1 with note: Triggered by commit
Building remotely on LinuxSlave - 3 in workspace 

Running Prebuild steps
[kwallet-framework_master_qt5] $ /bin/sh -xe /tmp/hudson3367697906544303982.sh
+ /home/jenkins/scripts/setup-env.sh

Preparing to perform KDE Continuous Integration build
== Setting Up Sources

>From git://anongit.kde.org/kwallet-framework
   35877a4..89d1dad  master -> origin/master
Branch jenkins set up to track remote branch master from origin.

== Cleaning Source Tree

HEAD is now at 35877a4 Merge branch 'master' of 
git://anongit.kde.org/kwallet-framework
Removing build/
Success build forhudson.tasks.Shell@23056bf9
Fetching changes from the remote Git repository
Fetching upstream changes from git://anongit.kde.org/kwallet-framework
Checking out Revision 89d1dadb37fcbed6e413f5438f51070cec4251fd 
(refs/heads/jenkins)
Run condition [File exists] enabling prebuild for step [Publish JUnit test 
result report]
Run condition [File exists] enabling prebuild for step [Publish Cppcheck 
results]
[kwallet-framework_master_qt5] $ /bin/sh -xe /tmp/hudson6608207006433612148.sh
+ /home/jenkins/scripts/execute-job.sh

KDE Continuous Integration Build
== Building Project: kwallet-framework - Branch master
== Build Dependencies:
 kwindowsystem - Branch master
 qt5 - Branch stable
 kconfig - Branch master
 extra-cmake-modules - Branch master
 cmake - Branch master

== Applying Patches
=== No patches to apply

== Syncing Dependencies from Master Server


== Configuring Build

-- The C compiler identification is GNU 4.7.2
-- The CXX compiler identification is GNU 4.7.2
-- Check for working C compiler: /home/jenkins/bin/cc
-- Check for working C compiler: /home/jenkins/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /home/jenkins/bin/c++
-- Check for working CXX compiler: /home/jenkins/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Performing Test __KDE_HAVE_W_OVERLOADED_VIRTUAL
-- Performing Test __KDE_HAVE_W_OVERLOADED_VIRTUAL - Success
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success
CMake Error at src/runtime/kwalletd/CMakeLists.txt:6 (find_package):
  Could not find a package configuration file provided by "KF5I18n" with any
  of the following names:

KF5I18nConfig.cmake
kf5i18n-config.cmake

  Add the installation prefix of "KF5I18n" to CMAKE_PREFIX_PATH or set
  "KF5I18n_DIR" to a directory containing one of the above files.  If
  "KF5I18n" provides a separate development package or SDK, be sure it has
  been installed.


-- Configuring incomplete, errors occurred!
See also 
"
Configure step exited with non-zero code, assuming failure to configure for 
project kwallet-framework.
Build step 'Execute shell' marked build as failure
[File exists] check if file exists [build/JUnitTestResults.xml]
Run condition [File exists] preventing perform for step [Publish JUnit test 
result report]
[File exists] check if file exists [build/cppcheck.xml]
Run condition [File exists] preventing perform for step [Publish Cppcheck 
results]
[WARNINGS] Skipping publisher since build result is FAILURE
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Build failed in Jenkins: kwallet-framework_master_qt5 #11

[KDE CI System]

See 

Changes:

[kde] Fix build

--
Started by remote host 127.0.0.1 with note: Triggered by commit
Building remotely on LinuxSlave - 4 in workspace 

Running Prebuild steps
[kwallet-framework_master_qt5] $ /bin/sh -xe /tmp/hudson7606600311331935636.sh
+ /home/jenkins/scripts/setup-env.sh

Preparing to perform KDE Continuous Integration build
== Setting Up Sources

>From git://anongit.kde.org/kwallet-framework
   c459593..752a6aa  master -> origin/master
Branch jenkins set up to track remote branch master from origin.

== Cleaning Source Tree

HEAD is now at c459593 Update REAMDE
Removing build/
Removing install/
Success build forhudson.tasks.Shell@23056bf9
Fetching changes from the remote Git repository
Fetching upstream changes from git://anongit.kde.org/kwallet-framework
Checking out Revision 752a6aaa9158d02db0be08662a2fbaeffa369c7d 
(refs/heads/jenkins)
Run condition [File exists] enabling prebuild for step [Publish JUnit test 
result report]
Run condition [File exists] enabling prebuild for step [Publish Cppcheck 
results]
[kwallet-framework_master_qt5] $ /bin/sh -xe /tmp/hudson3761497490603116667.sh
+ /home/jenkins/scripts/execute-job.sh

KDE Continuous Integration Build
== Building Project: kwallet-framework - Branch master
== Build Dependencies:
 kwindowsystem - Branch master
 qt5 - Branch stable
 cmake - Branch master
 kconfig - Branch master
 extra-cmake-modules - Branch master

== Applying Patches
=== No patches to apply

== Syncing Dependencies from Master Server


== Configuring Build

-- The C compiler identification is GNU 4.7.2
-- The CXX compiler identification is GNU 4.7.2
-- Check for working C compiler: /home/jenkins/bin/cc
-- Check for working C compiler: /home/jenkins/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /home/jenkins/bin/c++
-- Check for working CXX compiler: /home/jenkins/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Performing Test __KDE_HAVE_W_OVERLOADED_VIRTUAL
-- Performing Test __KDE_HAVE_W_OVERLOADED_VIRTUAL - Success
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success
CMake Error at src/runtime/kwalletd/CMakeLists.txt:5 (find_package):
  Could not find a package configuration file provided by "KF5Init" with any
  of the following names:

KF5InitConfig.cmake
kf5init-config.cmake

  Add the installation prefix of "KF5Init" to CMAKE_PREFIX_PATH or set
  "KF5Init_DIR" to a directory containing one of the above files.  If
  "KF5Init" provides a separate development package or SDK, be sure it has
  been installed.


-- Configuring incomplete, errors occurred!
See also 
"
Configure step exited with non-zero code, assuming failure to configure for 
project kwallet-framework.
Build step 'Execute shell' marked build as failure
[File exists] check if file exists [build/JUnitTestResults.xml]
Run condition [File exists] preventing perform for step [Publish JUnit test 
result report]
[File exists] check if file exists [build/cppcheck.xml]
Run condition [File exists] preventing perform for step [Publish Cppcheck 
results]
[WARNINGS] Skipping publisher since build result is FAILURE
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Build failed in Jenkins: kwallet-framework_master_qt5 #10

[KDE CI System]

See 

Changes:

[winter] signals: -> Q_SIGNALS and slots: -> Q_SLOTS

[coolo] merge in the kconfiggroup_port branch:

[mueller] fix various issues with non-compiling headers

[mueller] some more #include cleanup

[aseigo] this is now org.kde.screensaver

[coolo] port to standard (compare

[scripty] SVN_SILENT made messages (.desktop file)

[aseigo] oxygen icon naming fixes, courtesy of Luca Gugelmann

[scripty] SVN_SILENT made messages (.desktop file)

[scripty] SVN_SILENT made messages (.desktop file)

[l.lunak] Merge classes KWin and KWinModule into KWM (KDE Window Management - 
I'm bad at names

[ranger] fix KWM:: stuff on !X11

[scripty] SVN_SILENT made messages (.desktop file)

[mueller] include cleanup

[pino] port (or attempt to) the KWallet wizard to the new QWizard

[pino] temporary disable the tests, as it seems they do not compile well at the 
moment...

[scripty] SVN_SILENT made messages (.desktop file)

[binner] revert "Open" -> "Open..." parts of commit 537984

[kde] Includes (EBN) fixes

[faure] Merge libkwalletclient into libkdeui (since it only requires kdecore + 
qtgui); a lib for one class (which kio uses anyway) is overkill.

[l.lunak] KWM->KWindowSystem

[mueller] include cleanup

[faure] Simplify: use qt4_generate_dbus_interface now that it can take the name 
of the xml file as argument

[kde] Add licenses.  Checked with George Staikos.

[scripty] SVN_SILENT made messages (.desktop file)

[scripty] SVN_SILENT made messages (.desktop file)

[faure] Q3IntDict -> QHash. kwalletd is Qt3support free now.

[scripty] SVN_SILENT made messages (.desktop file)

[scripty] SVN_SILENT made messages (.desktop file)

[scripty] SVN_SILENT made messages (.desktop file)

[scripty] SVN_SILENT made messages (.desktop file)

[apaku] As discussed on kde-buildsystem rename kde4_add_test to

[scripty] SVN_SILENT made messages (.desktop file)

[scripty] SVN_SILENT made messages (.desktop file)

[uwolfer] enable test, works fine here

[uwolfer] hopefully fix dashboard compile errors

[winter] remove kde4_automoc(), thanks to Matthias.

[pino] take the .ui files as part of the test, relying on what was compiled in 
the top-level does not really work when using more than one compiling job

[scripty] SVN_SILENT made messages (.desktop file)

[scripty] SVN_SILENT made messages (.desktop file)

[montel] Adapt to new kdebug api

[scripty] SVN_SILENT made messages (.desktop file)

[scripty] SVN_SILENT made messages (.desktop file)

[scripty] SVN_SILENT made messages (.desktop file)

[scripty] SVN_SILENT made messages (.desktop file)

[scripty] SVN_SILENT made messages (.desktop file)

[amthpublic] strictly i18n html tags and typo fixes, no code changed

[amthpublic] SVN_SILENT include duplicate-- + few malformed markup fixes

[scripty] SVN_SILENT made messages (.desktop file)

[kde] SVN_SILENT: deprecated--

[scripty] SVN_SILENT made messages (.desktop file)

[scripty] SVN_SILENT made messages (.desktop file)

[montel] Fix ui files

[scripty] SVN_SILENT made messages (.desktop file)

[montel] Adapt CMakeLists.txt as discussed with Alex.

[scripty] SVN_SILENT made messages (.desktop file)

[scripty] SVN_SILENT made messages (.desktop file)

[scripty] SVN_SILENT made messages (.desktop file)

[scripty] SVN_SILENT made messages (.desktop file)

[scripty] SVN_SILENT made messages (.desktop file)

[ossi] KConfig* API overhaul. only cosmetics, so don't panic.

[ch.ehrlicher] kssld and kwalletd also compile on win32

[scripty] SVN_SILENT made messages (.desktop file)

[faure] Ported all kdelibs-provided kded modules to KPluginFactory.

[winter] various fixes:

[scripty] SVN_SILENT made messages (.desktop file)

[ch.ehrlicher] somehow I need QTimer here

[scripty] SVN_SILENT made messages (.desktop file)

[scripty] SVN_SILENT made messages (.desktop file)

[scripty] SVN_SILENT made messages (.desktop file)

[scripty] SVN_SILENT made messages (.desktop file)

[scripty] SVN_SILENT made messages (.desktop file)

[scripty] SVN_SILENT made messages (.desktop file)

[robertknight] Add a window title to the KWallet first-run wizard.  The string 
'KDE Wallet Service' (already used elsewhere) is used instead of 'KDE Wallet 
Wizard' because of the string freeze

[scripty] SVN_SILENT made messages (.desktop file)

[scripty] SVN_SILENT made messages (.desktop file)

[scripty] SVN_SILENT made messages (.desktop file)

[scripty] SVN_SILENT made messages (.desktop file)

[scripty] SVN_SILENT made messages (.desktop file)

[scripty] SVN_SILENT made messages (.desktop file)

[scripty] SVN_SILENT made messages (.desktop file)

[kde] Set X-KDE-DBus-Module for all KDEDModules.

[scripty] SVN_SILENT made messages (.desktop file)

[scripty] SVN_SILENT made messages (.desktop file)

[scripty] SVN_SILENT made messages (.desktop file, second try)

[lemma] Save changes to the wallet immediately using a timer with a delay of 5s.

[lemma] Separate kwalletd from kded and make it a stand-a

Re: Review Request 115004: use KDeclarative namespace for kdeclarative framework classes

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115004/
---

(Updated Jan. 13, 2014, 8:02 p.m.)


Review request for KDE Frameworks and Plasma.


Repository: kdeclarative


Description
---

KDeclarative has very generic class names, therefore a bad practiche for public 
symbols.
this moves it under KDeclarative:: namespace as discussed in the sprint


Diffs
-

  src/configpropertymap.h aeb41b5 
  src/configpropertymap.cpp 73e21d8 
  src/kdeclarative.h 84e8df4 
  src/kdeclarative.cpp 8aed99c 
  src/private/kdeclarative_p.h 91e83cc 
  src/private/kiconprovider.cpp 27eb8d1 
  src/private/kiconprovider_p.h 3773e0c 
  src/private/kioaccessmanagerfactory.cpp ea73c45 
  src/private/kioaccessmanagerfactory_p.h 7f7cc73 
  src/private/qmlobject_p.h e5b32f8 
  src/private/rootcontext.cpp 503b430 
  src/private/rootcontext_p.h 805f7fa 
  src/qmlobject.h 5028559 
  src/qmlobject.cpp d00ff40 
  tests/kdeclarativetest.cpp dd34d88 

Diff: https://git.reviewboard.kde.org/r/115004/diff/


Testing
---


Thanks,

Marco Martin

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: kwalletd about to be switched from kde-runtime to kwallet-framework

[Valentin Rusu]

On 01/13/2014 08:40 PM, Kevin Ottens wrote:
> On Monday 13 January 2014 20:12:31 Valentin Rusu wrote:
>> On 01/13/2014 07:54 PM, David Faure wrote:
>>> On Monday 13 January 2014 16:48:52 Nicolás Alvarez wrote:
 2014/1/13 David Faure :

 If you rename kwallet to kwalletmanager and kwallet-framework to
 kwallet, people with a clone of "kwallet.git" will get a mess the next
 time they pull from the server, as the entire repository/history will
 have changed.
>>>
>>> Maybe kwallet -> kwalletmanager, then wait for a few months,
>>> then kwallet-framework-> kwallet?
>>>
>>> That would give time to anyone having a kwallet clone to get errors
>>> and re-clone?
>>
>> Here is one more reason to move kwalletmanager (aka kdeutils/kwallet) in
>> kwallet-framework. Then there'll be no more such problems.
>>
>> Will that be acceptable for our packagers?
> 
> Honestly I think that makes sense to keep the manager application from the 
> daemon and interface. We don't provide the KCM to control the emoticons with 
> kemoticons for instance, it's more workspace stuff.


Well, I see. So I'll do like David sugests.




signature.asc
Description: OpenPGP digital signature
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: kwalletd about to be switched from kde-runtime to kwallet-framework

[Kevin Ottens]

On Monday 13 January 2014 20:12:31 Valentin Rusu wrote:
> On 01/13/2014 07:54 PM, David Faure wrote:
> > On Monday 13 January 2014 16:48:52 Nicolás Alvarez wrote:
> >> 2014/1/13 David Faure :
> >> 
> >> If you rename kwallet to kwalletmanager and kwallet-framework to
> >> kwallet, people with a clone of "kwallet.git" will get a mess the next
> >> time they pull from the server, as the entire repository/history will
> >> have changed.
> > 
> > Maybe kwallet -> kwalletmanager, then wait for a few months,
> > then kwallet-framework-> kwallet?
> > 
> > That would give time to anyone having a kwallet clone to get errors
> > and re-clone?
> 
> Here is one more reason to move kwalletmanager (aka kdeutils/kwallet) in
> kwallet-framework. Then there'll be no more such problems.
> 
> Will that be acceptable for our packagers?

Honestly I think that makes sense to keep the manager application from the 
daemon and interface. We don't provide the KCM to control the emoticons with 
kemoticons for instance, it's more workspace stuff.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com



signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: kwalletd about to be switched from kde-runtime to kwallet-framework

[Valentin Rusu]

On 01/13/2014 07:54 PM, David Faure wrote:
> On Monday 13 January 2014 16:48:52 Nicolás Alvarez wrote:
>> 2014/1/13 David Faure :
>>
>> If you rename kwallet to kwalletmanager and kwallet-framework to
>> kwallet, people with a clone of "kwallet.git" will get a mess the next
>> time they pull from the server, as the entire repository/history will
>> have changed.
> 
> Maybe kwallet -> kwalletmanager, then wait for a few months, 
> then kwallet-framework-> kwallet?
> 
> That would give time to anyone having a kwallet clone to get errors
> and re-clone?
> 

Here is one more reason to move kwalletmanager (aka kdeutils/kwallet) in
kwallet-framework. Then there'll be no more such problems.

Will that be acceptable for our packagers?




signature.asc
Description: OpenPGP digital signature
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: kwalletd about to be switched from kde-runtime to kwallet-framework

[Valentin Rusu]

On 01/13/2014 05:17 PM, Kevin Ottens wrote:
> Hello,
> 
> On Monday 13 January 2014 10:05:26 David Faure wrote:
>> On Sunday 12 January 2014 19:59:26 Valentin Rusu wrote:

>>
>> Do you also plan on doing something with the "kwallet" repository,
>> i.e. the user-facing application?

Well, if you asked me, I would also import kdeutils/kwallet in
kwallet-framework, as it's related technology for me. But I got some
feedback about systems where kwalletd is present and not kwalletmanager.

>> I guess it makes some sense for it to rename separate, but maybe in that
>> case its git repo should be "kwalletmanager" and "kwallet-framework" should
>> be "kwallet" (the -framework suffix was just a quick hack to solve the name
>> clash when splitting out the repos).
> 
> Definitely makes sense to me. We probably want such a repository renaming.

Yes, I also agree. I'll take care of that.

Regards,




signature.asc
Description: OpenPGP digital signature
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: kwalletd about to be switched from kde-runtime to kwallet-framework

[David Faure]

On Monday 13 January 2014 16:48:52 Nicolás Alvarez wrote:
> 2014/1/13 David Faure :
> > On Sunday 12 January 2014 19:59:26 Valentin Rusu wrote:
> >> Hello,
> >> 
> >> Please be informed that I successfully imported the git history of
> >> kwalletd from kde-runtime to kwallet-framework, the I ported it to KF5.
> >> The code is ready to be pushed, but there are 430 commits waiting on my
> >> local copy. I filed a sysadmin ticket and as soon as it gets handled,
> >> I'll push it.
> >> 
> >> After that, and if no one objects, I'll do the "git rm -rf kwalletd"
> >> from frameworks branch of kde-runtime, also adjusting the main
> >> CMakeLists.txt.
> > 
> > Sounds good, thanks!
> > 
> > Do you also plan on doing something with the "kwallet" repository,
> > i.e. the user-facing application?
> > I guess it makes some sense for it to rename separate, but maybe in that
> > case its git repo should be "kwalletmanager" and "kwallet-framework"
> > should be "kwallet" (the -framework suffix was just a quick hack to solve
> > the name clash when splitting out the repos).
> 
> If you rename kwallet to kwalletmanager and kwallet-framework to
> kwallet, people with a clone of "kwallet.git" will get a mess the next
> time they pull from the server, as the entire repository/history will
> have changed.

Maybe kwallet -> kwalletmanager, then wait for a few months, 
then kwallet-framework-> kwallet?

That would give time to anyone having a kwallet clone to get errors
and re-clone?

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: kwalletd about to be switched from kde-runtime to kwallet-framework

[Nicolás Alvarez]

2014/1/13 David Faure :
> On Sunday 12 January 2014 19:59:26 Valentin Rusu wrote:
>> Hello,
>>
>> Please be informed that I successfully imported the git history of
>> kwalletd from kde-runtime to kwallet-framework, the I ported it to KF5.
>> The code is ready to be pushed, but there are 430 commits waiting on my
>> local copy. I filed a sysadmin ticket and as soon as it gets handled,
>> I'll push it.
>>
>> After that, and if no one objects, I'll do the "git rm -rf kwalletd"
>> from frameworks branch of kde-runtime, also adjusting the main
>> CMakeLists.txt.
>
> Sounds good, thanks!
>
> Do you also plan on doing something with the "kwallet" repository,
> i.e. the user-facing application?
> I guess it makes some sense for it to rename separate, but maybe in that case
> its git repo should be "kwalletmanager" and "kwallet-framework" should be
> "kwallet" (the -framework suffix was just a quick hack to solve the name clash
> when splitting out the repos).

If you rename kwallet to kwalletmanager and kwallet-framework to
kwallet, people with a clone of "kwallet.git" will get a mess the next
time they pull from the server, as the entire repository/history will
have changed.

-- 
Nicolás
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

KDE Frameworks: Looking for maintainers

[Kevin Ottens]

Hello everyone,

This is a reminder that we're still looking for maintainers for our 
frameworks. Out of the 57 existing frameworks 33 have no maintainer (yes, 
that's almost 60%). I don't know about you, but I find that worrying.

The modules without maintainers are spread this way:
 - 9 are tier 1 (so depending only on Qt);
 - 7 are tier 2 (depending on Qt and a couple of tier 1);
 - 14 are tier 3 (larger dependencies)
 - 3 are tier 4 (kde4support and modules helping for platform integration).

I'd like to thanks all the people who already stepped up to become frameworks 
maintainers! And for those still hiding in the dark, here is your chance at 
providing a very critical service to our community!

If you hesitate on becoming a maintainer, feel free to get in touch with me, 
we can probably work together to find something where you'll feel at home. If 
you have a calling to become a maintainer and already have well formed tastes 
and responsibilities you'd like to take, head to the wiki and book one of the 
frameworks:
http://community.kde.org/Frameworks/List

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com



signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KNewStuff3 vs. KNS3 vs. KNewStuff (was: Re: What are the plans with CamelCase includes?)

[David Faure]

On Monday 13 January 2014 17:50:25 Friedrich W. H. Kossebau wrote:
> Those knewstuff3/file.h forwarding headers you are proposing, they would be 
> installed from KDE4Support, right? To [...]/include/KF5/knewstuff3, with
> the pattern...
> file "entry.h" contains: "#include "

Ah, good idea. There's a bunch of forwarding headers I wrote for SC reasons 
that should move to kde4support too...
Well, including knewstuffbutton.h, for knewstuff. You'll move it too?

> And all include/KF5/KDE/KNS3/* forwarding headers would be changed from 
> "#include " to "#include " as well.

Yep.

> Would update/prepare RRs for both kde4support and knewstuff modules, if I
> got  the proposal right and noone objects.

Sounds good to me.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Integrating kf5dot and kapidox

[Aurélien Gâteau]

Hi,

Now that kf5dot is (hopefully) mostly feature-complete
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

kf5dot now supports extra dependencies

[Aurélien Gâteau]

Hi,

Just a quick note to let you know I finally finished adding support
for "explicit" dependencies to kf5dot. This makes it possible to
express dependencies between frameworks which are not included in the
Graphviz files generated by CMake.

This happens in kdnssd, because depending on the system configuration
it will build either an Avahi or a Dnssd backend, and only the later
requires KConfig. It also happens with kded, which depends on macros
provided by kinit, but does not actually link to any target provided
by kinit.

The way to express those dependencies is through the yaml file. For
illustration, here is kded.yaml:

tier: 3

framework-dependencies:
# kded depends on CMake macros provided by kinit
- kinit

Updated diagrams are available at http://agateau.com/tmp/kf5

Which reminds me I need to document the format of this yaml file...

Aurélien
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: New doxygen script

[Alex Merry]

On 13/01/14 16:15, Aurélien Gâteau wrote:
> Thanks a lot! I think you should merge your work in already. Once your
> script
> can generate a proper index.html page we can ask Allen to set up
> api.kde.org to
> use it for frameworks doc.

I'm mostly waiting on the review requests I have outstanding - in
particular, there's some stuff that should be moved to kdoctools, and
I'd like to do that first.

> Oh, don't forget to document the way it works in the README.md :)

I've documented how to use it in the README.md.  How it works probably
belongs in comments at the top of the scripts.

> The main KDE website is actually expected to be refreshed at some point
> to use
> the same appearance as bugs.kde.org or forum.kde.org, so we might want
> to skip
> the current kde.org look. Furthermore I don't think the current image
> background
> is very adapted for API documentation.

Yeah, I also couldn't find a good place for the api search box.  We can
re-visit the look later.

> I am not very fond of two-level menus to be honest. I find a sidebar
> easier to
> use. At one point I got http://api.kde.org/frameworks/kdelibs-apidocs/
> sidebar
> to look like this:
> 
> * Tier 1
> - kconfig
> - kcoreaddons
> - ...
> * Tier 2
> - kauth
> - ki18n
> - ...

Already done :-)

Alex

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KNewStuff3 vs. KNS3 vs. KNewStuff (was: Re: What are the plans with CamelCase includes?)

[Friedrich W. H. Kossebau]

Am Montag, 13. Januar 2014, 09:40:57 schrieb David Faure:
> On Saturday 11 January 2014 02:42:20 Friedrich W. H. Kossebau wrote:
> > There the used namespace does not match the module name:
> > namespace is "KNS3", the module name "KNewStuff3".
> 
> That's not a problem, the KIOCore module uses namespace (and therefore
> prefix) KIO.
> 
> I just saw this mail, after my reply to reviewboard. It seems that I missed
> one thing: that the actual C++ namespace is KNS3.

(And I missed before that PREFIX is also used for generating the forwarding 
path inside the CamelCase header, tested before only with KNewStuff3 as prefix 
and then did change to KNS3 without e.g. recompiling Okteta, just did make 
install in frameworks/knewstuff and that worked (tm), blame on me :) )

> Then there is indeed the option of making it KNS3/File and kns3/file.h, for
> more consistency (this time "with the C++ namespace"), at the cost of a
> greater SIC. But you could install knewstuff3/file.h forwarding headers for
> compatibility.

Would agree that this option is the more consistent one.

Those knewstuff3/file.h forwarding headers you are proposing, they would be 
installed from KDE4Support, right? To [...]/include/KF5/knewstuff3, with the 
pattern...
file "entry.h" contains: "#include "

And all include/KF5/KDE/KNS3/* forwarding headers would be changed from 
"#include " to "#include " as well.

Would update/prepare RRs for both kde4support and knewstuff modules, if I got 
the proposal right and noone objects.

Cheers
Friedrich
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KDE Frameworks on Inqlude

[Alex Merry]

On 13/01/14 16:17, Kevin Ottens wrote:
> Also makes me wonder if we're duplicating information from 
> http://community.kde.org/Frameworks/List
> If we duplicate too much of it, we might want to rely completely on the 
> information from the repositories since they're used by inqlude. We could 
> just 
> generate a page replacing the current wiki page.

I think that would be a good idea.  The type, platforms and maintainer
could all go in .yaml, which already contains the tier.

Alex
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: kwalletd about to be switched from kde-runtime to kwallet-framework

[Kevin Ottens]

Hello,

On Monday 13 January 2014 10:05:26 David Faure wrote:
> On Sunday 12 January 2014 19:59:26 Valentin Rusu wrote:
> > Please be informed that I successfully imported the git history of
> > kwalletd from kde-runtime to kwallet-framework, the I ported it to KF5.
> > The code is ready to be pushed, but there are 430 commits waiting on my
> > local copy. I filed a sysadmin ticket and as soon as it gets handled,
> > I'll push it.
> > 
> > After that, and if no one objects, I'll do the "git rm -rf kwalletd"
> > from frameworks branch of kde-runtime, also adjusting the main
> > CMakeLists.txt.
> 
> Sounds good, thanks!
> 
> Do you also plan on doing something with the "kwallet" repository,
> i.e. the user-facing application?
> I guess it makes some sense for it to rename separate, but maybe in that
> case its git repo should be "kwalletmanager" and "kwallet-framework" should
> be "kwallet" (the -framework suffix was just a quick hack to solve the name
> clash when splitting out the repos).

Definitely makes sense to me. We probably want such a repository renaming.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com


signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KDE Frameworks on Inqlude

[Kevin Ottens]

Hello,

On Sunday 12 January 2014 23:11:09 Cornelius Schumacher wrote:
> KDE Frameworks now have a dedicated page on Inqlude. There is a group
> listing all frameworks at http://inqlude.org/groups/kde-frameworks.html.
> The intention is not to make them stand out, but to have a logical grouping
> and one view to see them all at a glance.
> 
> The data is taken from the READMEs in the git repository. It's not
> automatically extracted, so changes in the READMEs won't be synced
> immediately, but need to be transferred to the Inqlude manifests. The
> inqlude command line tool has an option to do that. I plan to sync the data
> from time to time, in particular after releases.

Great to see! Looks like we'll be inqlude ready early on. :-)

> The release information currently is still missing on Inqlude. At the moment
> the frameworks are listed as generic libraries without a specific release.
> I plan to add the release info soon.

Anything we can do to help you with that?

Also makes me wonder if we're duplicating information from 
http://community.kde.org/Frameworks/List
If we duplicate too much of it, we might want to rely completely on the 
information from the repositories since they're used by inqlude. We could just 
generate a page replacing the current wiki page.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com


signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

KF5 Update Meeting 2014-w3 Reminder

[Kevin Ottens]

Hello all,

Just a quick reminder:
The next KF5 Update Meeting will happen on #kde-devel tomorrow at 4pm Paris 
time.

See you there!

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com



signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KDE Frameworks on Inqlude

[Jos Poortvliet]

On Sunday 12 January 2014 23:11:09 Cornelius Schumacher wrote:
> KDE Frameworks now have a dedicated page on Inqlude. There is a group
> listing all frameworks at http://inqlude.org/groups/kde-frameworks.html.
> The intention is not to make them stand out, but to have a logical
> grouping and one view to see them all at a glance.
> 
> The data is taken from the READMEs in the git repository. It's not
> automatically extracted, so changes in the READMEs won't be synced
> immediately, but need to be transferred to the Inqlude manifests. The
> inqlude command line tool has an option to do that. I plan to sync the
> data from time to time, in particular after releases.
> 
> The release information currently is still missing on Inqlude. At the
> moment the frameworks are listed as generic libraries without a specific
> release. I plan to add the release info soon.
> 
> The data itself also needs a little bit of love. The descriptions can be
> improved in some places, additional links, e.g. to tutorials or API
> documentation need to be added, and each framework should have a nice home
> page.
> 
> But for now it is a decent start. Thanks to all the people who put so much
> effort into preparing the frameworks for their first release.

Great work, Cornelius!

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 114990: removing kde4 references from kauth

[Siddharth Sharma]

Thanks looking into porting guide , will do legitimate requests next time.
:)

~siddharth


On Mon, Jan 13, 2014 at 6:15 PM, Alex Merry  wrote:

> On 13/01/14 12:41, Siddharth Sharma wrote:
> > so basically of all yesterdays review requests, were to know if things
> > would change over there or not. did not replaced everything with kde4 ->
> > kde5
>
> OK, sorry if I came across a bit harsh; I know you're still getting
> familiar with the frameworks.  The porting guide is a good first place
> to look, though.
>
> Alex
>



-- 
Skrooge, a personal finances manager powered by KDE 4.x
http://skrooge.org
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 114990: removing kde4 references from kauth

[Alex Merry]

On 13/01/14 12:41, Siddharth Sharma wrote:
> so basically of all yesterdays review requests, were to know if things
> would change over there or not. did not replaced everything with kde4 ->
> kde5

OK, sorry if I came across a bit harsh; I know you're still getting
familiar with the frameworks.  The porting guide is a good first place
to look, though.

Alex
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 114990: removing kde4 references from kauth

[Siddharth Sharma]

so basically of all yesterdays review requests, were to know if things
would change over there or not. did not replaced everything with kde4 ->
kde5



On Mon, Jan 13, 2014 at 5:39 PM, Alex Merry  wrote:

>This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/114990/
>
> src/kauthactionreply.h
>  (Diff
> revision 1)157
>
>  kde4_add_executable( your sources...)
>
> 157
>
>  kde5_add_executable( your sources...)
>
>   There is no such thing as kde5_add_executable().
>
> Please have a look through http://community.kde.org/Frameworks/Porting_Notes 
> for how the changes should actually be made.  In particular, the first 
> section (Build System) says how CMake calls are changed.  In particular, 
> there are *NO* cmake macros starting "kde5_".
>
>
>
> src/kauthactionreply.h
>  (Diff
> revision 1)173
>
>  kde4_install_auth_actions( )
>
> 173
>
>  kde5_install_auth_actions( )
>
>   I'm sure no such macro exists.  Have a look in 
> kauth/cmake/KF5AuthMacros.cmake for what it should become.
>
>
> - Alex Merry
>
> On January 12th, 2014, 8:12 p.m. UTC, Siddharth Sharma wrote:
>   Review request for KDE Frameworks.
> By Siddharth Sharma.
>
> *Updated Jan. 12, 2014, 8:12 p.m.*
>  *Repository: * kauth
> Description
>
> removing kde4 references from kauth
>
>   Testing
>
> none
>
>   Diffs
>
>- src/kauthactionreply.h (a7d2020)
>
> View Diff 
>



-- 
Skrooge, a personal finances manager powered by KDE 4.x
http://skrooge.org
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 114997: Improve KAuth README.md

[Alex Merry]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/114997/
---

Review request for KDE Frameworks and Dario Freddi.


Repository: kauth


Description
---

Improve KAuth README.md

I'm not really familiar with KAuth, and got this info from skimming the code 
and techbase tutorial.  Could someone more familiar with it check that I 
haven't made any glaring errors?


Diffs
-

  README.md a8a011a147d2dcc0fb5db39e263412005a86def4 

Diff: https://git.reviewboard.kde.org/r/114997/diff/


Testing
---


Thanks,

Alex Merry

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 114987: khtml and other components from frameworks should use kde5_install , remove kde4 refs

[Alex Merry]

> On Jan. 13, 2014, 11:54 a.m., Alex Merry wrote:
> > Does kde5_install_icons even exist?  I can't find its definition in 
> > extra-cmake-modules.
> > 
> > You say you've done no testing; surely you should at least have tried a 
> > fresh configure, compile and install of khtml?

Also, I would ignore khtml for now.  It needs a substantial porting effort to 
remove its dependency on kde4support, and I don't think that's a priority for 
us right now.


- Alex


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/114987/#review47308
---


On Jan. 12, 2014, 8:01 p.m., Siddharth Sharma wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/114987/
> ---
> 
> (Updated Jan. 12, 2014, 8:01 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: khtml
> 
> 
> Description
> ---
> 
> khtml and other components from frameworks should use kde5_install , remove 
> kde4 refs
> 
> 
> Diffs
> -
> 
>   tests/pics/CMakeLists.txt 3d2f8d5 
> 
> Diff: https://git.reviewboard.kde.org/r/114987/diff/
> 
> 
> Testing
> ---
> 
> None
> 
> 
> Thanks,
> 
> Siddharth Sharma
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 114991: I think frameworks 5 should use kde5 based emoticons ? , though i am not sure changing it now would make any sense o_O ? would leave up to reviewers

[Alex Merry]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/114991/#review47311
---


Currently, it is still "kde4"; it is tied to kde-runtime/pics/emoticons.  I 
think that directory needs to be merged into the kemoticons framework, and then 
this line needs to match the installation location of that emoticons theme.

Do you think you could make a review request for that?

- Alex Merry


On Jan. 12, 2014, 8:22 p.m., Siddharth Sharma wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/114991/
> ---
> 
> (Updated Jan. 12, 2014, 8:22 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kemoticons
> 
> 
> Description
> ---
> 
> I think frameworks 5 should use kde5 based emoticons ? , though i am not sure 
> changing it now would make any sense o_O ? would leave up to reviewers
> 
> 
> Diffs
> -
> 
>   src/core/kemoticons.cpp bc72e16 
> 
> Diff: https://git.reviewboard.kde.org/r/114991/diff/
> 
> 
> Testing
> ---
> 
> none
> 
> 
> Thanks,
> 
> Siddharth Sharma
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 114990: removing kde4 references from kauth

[Alex Merry]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/114990/#review47310
---



src/kauthactionreply.h


There is no such thing as kde5_add_executable().

Please have a look through 
http://community.kde.org/Frameworks/Porting_Notes for how the changes should 
actually be made.  In particular, the first section (Build System) says how 
CMake calls are changed.  In particular, there are *NO* cmake macros starting 
"kde5_".



src/kauthactionreply.h


I'm sure no such macro exists.  Have a look in 
kauth/cmake/KF5AuthMacros.cmake for what it should become.


- Alex Merry


On Jan. 12, 2014, 8:12 p.m., Siddharth Sharma wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/114990/
> ---
> 
> (Updated Jan. 12, 2014, 8:12 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kauth
> 
> 
> Description
> ---
> 
> removing kde4 references from kauth
> 
> 
> Diffs
> -
> 
>   src/kauthactionreply.h a7d2020 
> 
> Diff: https://git.reviewboard.kde.org/r/114990/diff/
> 
> 
> Testing
> ---
> 
> none
> 
> 
> Thanks,
> 
> Siddharth Sharma
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 114989: kapidox and other components from frameworks should use kde5-config instead of kde4-config, remove kde4 references

[Alex Merry]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/114989/#review47309
---


kde5-config is not a thing.  kf5-config does, but is provided by kde4support, 
which other frameworks (other than khtml as a special case) cannot depend on.

What this should actually change to is
kcfg_compiler="kconfig_compiler"
(or just replace all instances of $kcfg_compiler in the file with 
kconfig_compiler) and require that PATH is set correctly.

You can't just do a search-and-replace of "kde4" with "kde5" in the 
repositories!

- Alex Merry


On Jan. 12, 2014, 8:08 p.m., Siddharth Sharma wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/114989/
> ---
> 
> (Updated Jan. 12, 2014, 8:08 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kapidox
> 
> 
> Description
> ---
> 
> kapidox and other components from frameworks should use kde5-config instead 
> of kde4-config, remove kde4 references
> 
> 
> Diffs
> -
> 
>   src/doxygen-preprocess-kcfg.sh 567a248 
> 
> Diff: https://git.reviewboard.kde.org/r/114989/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Siddharth Sharma
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 114987: khtml and other components from frameworks should use kde5_install , remove kde4 refs

[Alex Merry]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/114987/#review47308
---


Does kde5_install_icons even exist?  I can't find its definition in 
extra-cmake-modules.

You say you've done no testing; surely you should at least have tried a fresh 
configure, compile and install of khtml?

- Alex Merry


On Jan. 12, 2014, 8:01 p.m., Siddharth Sharma wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/114987/
> ---
> 
> (Updated Jan. 12, 2014, 8:01 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: khtml
> 
> 
> Description
> ---
> 
> khtml and other components from frameworks should use kde5_install , remove 
> kde4 refs
> 
> 
> Diffs
> -
> 
>   tests/pics/CMakeLists.txt 3d2f8d5 
> 
> Diff: https://git.reviewboard.kde.org/r/114987/diff/
> 
> 
> Testing
> ---
> 
> None
> 
> 
> Thanks,
> 
> Siddharth Sharma
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 114962: Improve dependency specifications

[Alex Merry]

> On Jan. 11, 2014, 8:02 p.m., Alex Merry wrote:
> > This should be using QT_REQUIRED_VERSION everywhere.  Actually, if you 
> > could change it in the other CMakeLists.txt files, that would be good.  
> > Then it can be shipped.
> 
> Michael Palimaka wrote:
> No worries, will do. I only explicitly wrote the version for consistency 
> because pretty much every single framework hardcodes 5.2.0 in non-root 
> CMakeLists.txt

I think that happened because the variable was introduced later, and whoever 
did it didn't think that there might be find_package calls in subdirectories.


- Alex


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/114962/#review47231
---


On Jan. 11, 2014, 10:43 a.m., Michael Palimaka wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/114962/
> ---
> 
> (Updated Jan. 11, 2014, 10:43 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> QtTest and QtConcurrent are only required for autotests, so no need to find 
> them unconditionally.
> QtWidgets is not actually used - QtGui is instead.
> 
> 
> Diffs
> -
> 
>   src/gui/CMakeLists.txt e6ef7468a1e736d5d0c0e601e24f961270f2d0f2 
>   autotests/CMakeLists.txt e4790f691f5a9ae2989faef742c31615713e0027 
>   CMakeLists.txt b794b4b35479525873c342e6a6aa6677b3f00513 
> 
> Diff: https://git.reviewboard.kde.org/r/114962/diff/
> 
> 
> Testing
> ---
> 
> Builds and tests pass without QtWidgets installed. Builds without QtTest and 
> QtConcurrent installed.
> 
> 
> Thanks,
> 
> Michael Palimaka
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 114888: Avoid "//" in path in generated headers

[Dan Vrátil]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/114888/
---

(Updated Jan. 13, 2014, 10:47 a.m.)


Status
--

This change has been marked as submitted.


Review request for Extra Cmake Modules and KDE Frameworks.


Repository: extra-cmake-modules


Description
---

When the RELATIVE parameter in ECMGenerateHeaders is empty or not set, the 
_actualheader variable would be defined to 
"/cmake/current/source/dir//lowercaseclassname.h". 

The double slash breaks RPM's debug symbols extraction, because it 
canonicalizes the path, so it's shortened by one "/". The shortening is done to 
avoid double-slash in the beginning of the path, which is non-POSIX. However 
from my understanding it's not possible to truncate the size of directory table 
by 1 byte, so the debugedit utility aborts and the entire rpmbuild fails. See a 
relevant bug report with further information: 
https://bugzilla.redhat.com/show_bug.cgi?id=304121 (comment #2)

This patch simply makes sure that EGH_RELATIVE is either empty, or non-empty 
and terminated with slash.

With this patch we are able to build solid and kdnssd frameworks with RPM build 
tools.


Diffs
-

  modules/ECMGenerateHeaders.cmake f72b1c0 

Diff: https://git.reviewboard.kde.org/r/114888/diff/


Testing
---

Successfully built solid and kdnssd frameworks with rpmbuild, other frameworks 
still build too.


Thanks,

Dan Vrátil

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 114888: Avoid "//" in path in generated headers

[Commit Hook]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/114888/#review47301
---


This review has been submitted with commit 
6e5dd4943be1200f9f7f6620d69f140428abff45 by Dan Vrátil to branch master.

- Commit Hook


On Jan. 13, 2014, 10:17 a.m., Dan Vrátil wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/114888/
> ---
> 
> (Updated Jan. 13, 2014, 10:17 a.m.)
> 
> 
> Review request for Extra Cmake Modules and KDE Frameworks.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> When the RELATIVE parameter in ECMGenerateHeaders is empty or not set, the 
> _actualheader variable would be defined to 
> "/cmake/current/source/dir//lowercaseclassname.h". 
> 
> The double slash breaks RPM's debug symbols extraction, because it 
> canonicalizes the path, so it's shortened by one "/". The shortening is done 
> to avoid double-slash in the beginning of the path, which is non-POSIX. 
> However from my understanding it's not possible to truncate the size of 
> directory table by 1 byte, so the debugedit utility aborts and the entire 
> rpmbuild fails. See a relevant bug report with further information: 
> https://bugzilla.redhat.com/show_bug.cgi?id=304121 (comment #2)
> 
> This patch simply makes sure that EGH_RELATIVE is either empty, or non-empty 
> and terminated with slash.
> 
> With this patch we are able to build solid and kdnssd frameworks with RPM 
> build tools.
> 
> 
> Diffs
> -
> 
>   modules/ECMGenerateHeaders.cmake f72b1c0 
> 
> Diff: https://git.reviewboard.kde.org/r/114888/diff/
> 
> 
> Testing
> ---
> 
> Successfully built solid and kdnssd frameworks with rpmbuild, other 
> frameworks still build too.
> 
> 
> Thanks,
> 
> Dan Vrátil
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 114888: Avoid "//" in path in generated headers

[David Faure]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/114888/#review47300
---

Ship it!


Ship It!

- David Faure


On Jan. 13, 2014, 10:17 a.m., Dan Vrátil wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/114888/
> ---
> 
> (Updated Jan. 13, 2014, 10:17 a.m.)
> 
> 
> Review request for Extra Cmake Modules and KDE Frameworks.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> When the RELATIVE parameter in ECMGenerateHeaders is empty or not set, the 
> _actualheader variable would be defined to 
> "/cmake/current/source/dir//lowercaseclassname.h". 
> 
> The double slash breaks RPM's debug symbols extraction, because it 
> canonicalizes the path, so it's shortened by one "/". The shortening is done 
> to avoid double-slash in the beginning of the path, which is non-POSIX. 
> However from my understanding it's not possible to truncate the size of 
> directory table by 1 byte, so the debugedit utility aborts and the entire 
> rpmbuild fails. See a relevant bug report with further information: 
> https://bugzilla.redhat.com/show_bug.cgi?id=304121 (comment #2)
> 
> This patch simply makes sure that EGH_RELATIVE is either empty, or non-empty 
> and terminated with slash.
> 
> With this patch we are able to build solid and kdnssd frameworks with RPM 
> build tools.
> 
> 
> Diffs
> -
> 
>   modules/ECMGenerateHeaders.cmake f72b1c0 
> 
> Diff: https://git.reviewboard.kde.org/r/114888/diff/
> 
> 
> Testing
> ---
> 
> Successfully built solid and kdnssd frameworks with rpmbuild, other 
> frameworks still build too.
> 
> 
> Thanks,
> 
> Dan Vrátil
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 114888: Avoid "//" in path in generated headers

[Dan Vrátil]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/114888/
---

(Updated Jan. 13, 2014, 11:17 a.m.)


Review request for Extra Cmake Modules and KDE Frameworks.


Repository: extra-cmake-modules


Description
---

When the RELATIVE parameter in ECMGenerateHeaders is empty or not set, the 
_actualheader variable would be defined to 
"/cmake/current/source/dir//lowercaseclassname.h". 

The double slash breaks RPM's debug symbols extraction, because it 
canonicalizes the path, so it's shortened by one "/". The shortening is done to 
avoid double-slash in the beginning of the path, which is non-POSIX. However 
from my understanding it's not possible to truncate the size of directory table 
by 1 byte, so the debugedit utility aborts and the entire rpmbuild fails. See a 
relevant bug report with further information: 
https://bugzilla.redhat.com/show_bug.cgi?id=304121 (comment #2)

This patch simply makes sure that EGH_RELATIVE is either empty, or non-empty 
and terminated with slash.

With this patch we are able to build solid and kdnssd frameworks with RPM build 
tools.


Diffs (updated)
-

  modules/ECMGenerateHeaders.cmake f72b1c0 

Diff: https://git.reviewboard.kde.org/r/114888/diff/


Testing
---

Successfully built solid and kdnssd frameworks with rpmbuild, other frameworks 
still build too.


Thanks,

Dan Vrátil

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: kwalletd about to be switched from kde-runtime to kwallet-framework

[David Faure]

On Sunday 12 January 2014 19:59:26 Valentin Rusu wrote:
> Hello,
> 
> Please be informed that I successfully imported the git history of
> kwalletd from kde-runtime to kwallet-framework, the I ported it to KF5.
> The code is ready to be pushed, but there are 430 commits waiting on my
> local copy. I filed a sysadmin ticket and as soon as it gets handled,
> I'll push it.
> 
> After that, and if no one objects, I'll do the "git rm -rf kwalletd"
> from frameworks branch of kde-runtime, also adjusting the main
> CMakeLists.txt.

Sounds good, thanks!

Do you also plan on doing something with the "kwallet" repository,
i.e. the user-facing application?
I guess it makes some sense for it to rename separate, but maybe in that case
its git repo should be "kwalletmanager" and "kwallet-framework" should be 
"kwallet" (the -framework suffix was just a quick hack to solve the name clash 
when splitting out the repos).

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KNewStuff3 vs. KNS3 vs. KNewStuff (was: Re: What are the plans with CamelCase includes?)

[David Faure]

On Saturday 11 January 2014 02:42:20 Friedrich W. H. Kossebau wrote:
> There the used namespace does not match the module name:
> namespace is "KNS3", the module name "KNewStuff3".

That's not a problem, the KIOCore module uses namespace (and therefore prefix) 
KIO.

I just saw this mail, after my reply to reviewboard. It seems that I missed 
one thing: that the actual C++ namespace is KNS3.

Then there is indeed the option of making it KNS3/File and kns3/file.h, for 
more consistency (this time "with the C++ namespace"), at the cost of a 
greater SIC. But you could install knewstuff3/file.h forwarding headers for 
compatibility.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 114988: Fix PREFIX parameter to ecm_generate_headers to match namespace KNS3

[David Faure]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/114988/#review47294
---


Well, then it breaks lowercase headers, which have been  at 
least since 2009.

Looking at kdelibs4:
install_manifest.txt:/d/kde/inst/kde4.12/include/knewstuff3/knewstuffaction.h
install_manifest.txt:/d/kde/inst/kde4.12/include/knewstuff3/knewstuffbutton.h
install_manifest.txt:/d/kde/inst/kde4.12/include/KDE/KNS3/KNewStuffAction
install_manifest.txt:/d/kde/inst/kde4.12/include/KDE/KNS3/KNewStuffButton
(and no forwarding headers for DownloadDialog, DownloadWidget, DownloadManager, 
UploadDialog or Entry)

This is inconsistent indeed. ecm_generate_prefix assumes that the prefix for 
camelcase and for lowercase headers is the same, apart from the case.

Oh! For sure there's a bug, I meant PREFIX KNewStuff3, rather than knewstuff3. 
This needs to be fixed.

I think this is more consistent than this patch, which will lead to 
kns3/entry.h etc. This would be a much bigger SIC than changing the prefix for 
camelcase headers, since KNewStuffButton is now Button anyway, and 
KNewStuffAction... hmm I didn't generate a forwarding header for it since it 
doesn't actually define such a class, but we can add that for SC reasons.

If we fix the PREFIX to KNewStuff3 then we get

-- Up-to-date: 
/d/kde/inst/kde_frameworks/include/KF5/KNewStuff3/KNewStuff3/DownloadDialog
-- Up-to-date: 
/d/kde/inst/kde_frameworks/include/KF5/KNewStuff3/KNewStuff3/DownloadWidget
-- Up-to-date: 
/d/kde/inst/kde_frameworks/include/KF5/KNewStuff3/KNewStuff3/UploadDialog
-- Up-to-date: 
/d/kde/inst/kde_frameworks/include/KF5/KNewStuff3/KNewStuff3/Button
-- Up-to-date: 
/d/kde/inst/kde_frameworks/include/KF5/KNewStuff3/KNewStuff3/DownloadManager
-- Up-to-date: 
/d/kde/inst/kde_frameworks/include/KF5/KNewStuff3/KNewStuff3/Entry

-- Up-to-date: 
/d/kde/inst/kde_frameworks/include/KF5/KNewStuff3/knewstuff3/knewstuff_export.h
-- Up-to-date: 
/d/kde/inst/kde_frameworks/include/KF5/KNewStuff3/knewstuff3/knewstuffaction.h
-- Up-to-date: 
/d/kde/inst/kde_frameworks/include/KF5/KNewStuff3/knewstuff3/knewstuffbutton.h
-- Up-to-date: 
/d/kde/inst/kde_frameworks/include/KF5/KNewStuff3/knewstuff3/downloaddialog.h
-- Up-to-date: 
/d/kde/inst/kde_frameworks/include/KF5/KNewStuff3/knewstuff3/downloadwidget.h
-- Up-to-date: 
/d/kde/inst/kde_frameworks/include/KF5/KNewStuff3/knewstuff3/downloadmanager.h
-- Up-to-date: 
/d/kde/inst/kde_frameworks/include/KF5/KNewStuff3/knewstuff3/uploaddialog.h
-- Up-to-date: 
/d/kde/inst/kde_frameworks/include/KF5/KNewStuff3/knewstuff3/entry.h
-- Up-to-date: 
/d/kde/inst/kde_frameworks/include/KF5/KNewStuff3/knewstuff3/button.h

Looks nice and consistent to me (including consistent with the other 
frameworks).

- David Faure


On Jan. 12, 2014, 8:15 p.m., Friedrich W. H. Kossebau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/114988/
> ---
> 
> (Updated Jan. 12, 2014, 8:15 p.m.)
> 
> 
> Review request for KDE Frameworks, Aleix Pol Gonzalez and David Faure.
> 
> 
> Repository: knewstuff
> 
> 
> Description
> ---
> 
> Currently the KNewStuff CamelCase forwarding headers are installed in 
> [...]/include/KF5/KNewStuff3/knewstuff3
> Which seems wrong, at least does not follow the pattern seen with the other 
> namespaced modules. And breaks all existing #includes if the build does not 
> use KDE4Support with its variants of the CamelCase forwarding headers.
> 
> Attached patch changes the PREFIX parameter to ecm_generate_headers from 
> knewstuff3 to KNS3, so that the prefix matches the namespace of the classes 
> in the module.
> 
> 
> Diffs
> -
> 
>   src/CMakeLists.txt 05cd500 
> 
> Diff: https://git.reviewboard.kde.org/r/114988/diff/
> 
> 
> Testing
> ---
> 
> Applied and run make install: CamelCase includes are installed in 
> [...]/include/KF5/KNewStuff3/KNS3 directory, code which #includes KNS3/* 
> without KDE4Support builds.
> 
> 
> Thanks,
> 
> Friedrich W. H. Kossebau
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel