Re: Review Request: Make the maximum # of connection per host in KIO::Scheduler user-configurable

2012-03-05 Thread David Faure

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104120/#review11139
---

Ship it!


Looks good to me, thanks for this long-due fix.

I don't know how well the underlying feature works (e.g. will the jobs wait for 
a connection or fail immediately, and will getConnectedSlave return 0 when the 
limit is reached) -- but this patch looks ok, it's just "more (configurability) 
of the same (feature)".


kio/kio/scheduler.cpp


Typo (salves)


- David Faure


On March 3, 2012, 5:48 p.m., Dawit Alemayehu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104120/
> ---
> 
> (Updated March 3, 2012, 5:48 p.m.)
> 
> 
> Review request for kdelibs and Andreas Hartmetz.
> 
> 
> Description
> ---
> 
> This patch is an alternate approach to making the number of ioslaves 
> connections allowed per server configurable by the user. Unlike the patch 
> proposed in bug# 64647, the approach taken in this patch neither requires any 
> new API additions to KIO::Scheduler nor does it limit configurablity per 
> protocol.
> 
> For restricting the number of ioslaves per server/host all a user would have 
> to do is add a "MaxInstancesPerHost" property to the specific protocols 
> configuration file. For example, to limit the number of ftp connections to 
> "ftp://ftp.foo.bar"; to 1, one would only have to add the following to 
> $KDEHOME/share/config/kio_ftprc:
> 
> [ftp.foo.bar]
> MaxInstancesPerHost=1
> 
> But that is not all. The user can make that restriction apply globally to all 
> ftp connections by simply moving property to the global section of of the 
> configuration file. That is move it out of the host ("[ftp.foo.bar]") 
> section. And to make it apply to every protocol, simply move the property to 
> the generic ioslave configuration file, $KDEHOME/share/config/kioslaverc.
> 
> 
> This addresses bug 64647.
> http://bugs.kde.org/show_bug.cgi?id=64647
> 
> 
> Diffs
> -
> 
>   kio/kio/scheduler.cpp 6b4ed52 
> 
> Diff: http://git.reviewboard.kde.org/r/104120/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dawit Alemayehu
> 
>



Re: Review Request: Avoid QDBusConnection Qt warning message for each KUniqueApplication

2012-03-05 Thread David Faure

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103699/#review11140
---


Looks ok to me, except for a few details. I presume you tested all 
combinations? The kuniqueapplication unit test, the new app case, the 
already-running app case, the --nofork case?


kdeui/kernel/kuniqueapplication.cpp


Is there a reason for this particular connection name? Seems to match one 
from Qt itself, can you add a comment about why this is wanted?



kdeui/kernel/kuniqueapplication.cpp


Qt/kdelibs coding style (for new code) is "no spaces inside parenthesis, 
opening brace on the same line".



kdeui/kernel/kuniqueapplication.cpp


Good idea, but please put the app name in a local var at the beginning of 
the method. It will reduce code duplication (I know it's not much code, but in 
kde frameworks 5 this will probably not come from KCmdLineArgs anymore).


- David Faure


On Jan. 15, 2012, 5:28 p.m., Martin Koller wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103699/
> ---
> 
> (Updated Jan. 15, 2012, 5:28 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Description
> ---
> 
> All KUniqueApplications issue the warning
> QDBusConnection: session D-Bus connection created before QCoreApplication. 
> Application may misbehave.
> when runngin with Qt-4.8.0 (qWarning in QDBusDefaultConnection ctor)
> 
> The patch avoids this by temporarily creating a QCoreApplication instance
> 
> 
> Diffs
> -
> 
>   kdeui/kernel/kuniqueapplication.cpp 777fc35 
> 
> Diff: http://git.reviewboard.kde.org/r/103699/diff/
> 
> 
> Testing
> ---
> 
> running kdepasswd
> 
> 
> Thanks,
> 
> Martin Koller
> 
>



Re: Review Request: Make the maximum # of connection per host in KIO::Scheduler user-configurable

2012-03-05 Thread Dawit Alemayehu


> On March 5, 2012, 3:19 p.m., David Faure wrote:
> > Looks good to me, thanks for this long-due fix.
> > 
> > I don't know how well the underlying feature works (e.g. will the jobs wait 
> > for a connection or fail immediately, and will getConnectedSlave return 0 
> > when the limit is reached) -- but this patch looks ok, it's just "more 
> > (configurability) of the same (feature)".

The jobs will be queued and they will wait until an ioslave becomes available 
to service them. For example, if you set the number of connections allowed to a 
ftp server to "1" and attempt to download two files, the requests will be 
handled one at a time. That is the download of the second file will not begin 
until the first download is either canceled or done.


- Dawit


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104120/#review11139
---


On March 3, 2012, 5:48 p.m., Dawit Alemayehu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104120/
> ---
> 
> (Updated March 3, 2012, 5:48 p.m.)
> 
> 
> Review request for kdelibs and Andreas Hartmetz.
> 
> 
> Description
> ---
> 
> This patch is an alternate approach to making the number of ioslaves 
> connections allowed per server configurable by the user. Unlike the patch 
> proposed in bug# 64647, the approach taken in this patch neither requires any 
> new API additions to KIO::Scheduler nor does it limit configurablity per 
> protocol.
> 
> For restricting the number of ioslaves per server/host all a user would have 
> to do is add a "MaxInstancesPerHost" property to the specific protocols 
> configuration file. For example, to limit the number of ftp connections to 
> "ftp://ftp.foo.bar"; to 1, one would only have to add the following to 
> $KDEHOME/share/config/kio_ftprc:
> 
> [ftp.foo.bar]
> MaxInstancesPerHost=1
> 
> But that is not all. The user can make that restriction apply globally to all 
> ftp connections by simply moving property to the global section of of the 
> configuration file. That is move it out of the host ("[ftp.foo.bar]") 
> section. And to make it apply to every protocol, simply move the property to 
> the generic ioslave configuration file, $KDEHOME/share/config/kioslaverc.
> 
> 
> This addresses bug 64647.
> http://bugs.kde.org/show_bug.cgi?id=64647
> 
> 
> Diffs
> -
> 
>   kio/kio/scheduler.cpp 6b4ed52 
> 
> Diff: http://git.reviewboard.kde.org/r/104120/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dawit Alemayehu
> 
>



Re: Review Request: Make the maximum # of connection per host in KIO::Scheduler user-configurable

2012-03-05 Thread Dawit Alemayehu

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

(Updated March 5, 2012, 3:46 p.m.)


Review request for kdelibs and Andreas Hartmetz.


Changes
---

Updated the Testing Done section for reference.


Description
---

This patch is an alternate approach to making the number of ioslaves 
connections allowed per server configurable by the user. Unlike the patch 
proposed in bug# 64647, the approach taken in this patch neither requires any 
new API additions to KIO::Scheduler nor does it limit configurablity per 
protocol.

For restricting the number of ioslaves per server/host all a user would have to 
do is add a "MaxInstancesPerHost" property to the specific protocols 
configuration file. For example, to limit the number of ftp connections to 
"ftp://ftp.foo.bar"; to 1, one would only have to add the following to 
$KDEHOME/share/config/kio_ftprc:

[ftp.foo.bar]
MaxInstancesPerHost=1

But that is not all. The user can make that restriction apply globally to all 
ftp connections by simply moving property to the global section of of the 
configuration file. That is move it out of the host ("[ftp.foo.bar]") section. 
And to make it apply to every protocol, simply move the property to the generic 
ioslave configuration file, $KDEHOME/share/config/kioslaverc.


This addresses bug 64647.
http://bugs.kde.org/show_bug.cgi?id=64647


Diffs
-

  kio/kio/scheduler.cpp 6b4ed52 

Diff: http://git.reviewboard.kde.org/r/104120/diff/


Testing (updated)
---

To verify correct behavior, I added the following settings to kio_ftprc and 
attempted to download multiple files at the same time. KIO::Scheduler correctly 
processed the request one at a time:

[ftp.kde.org]
MaxConnections=1


Thanks,

Dawit Alemayehu



Re: Review Request: Make the maximum # of connection per host in KIO::Scheduler user-configurable

2012-03-05 Thread Commit Hook

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104120/#review11142
---


This review has been submitted with commit 
7a5ecbd5316b880f86a2088f420057cdb8d4e2ba by Dawit Alemayehu to branch KDE/4.8.

- Commit Hook


On March 5, 2012, 3:46 p.m., Dawit Alemayehu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104120/
> ---
> 
> (Updated March 5, 2012, 3:46 p.m.)
> 
> 
> Review request for kdelibs and Andreas Hartmetz.
> 
> 
> Description
> ---
> 
> This patch is an alternate approach to making the number of ioslaves 
> connections allowed per server configurable by the user. Unlike the patch 
> proposed in bug# 64647, the approach taken in this patch neither requires any 
> new API additions to KIO::Scheduler nor does it limit configurablity per 
> protocol.
> 
> For restricting the number of ioslaves per server/host all a user would have 
> to do is add a "MaxInstancesPerHost" property to the specific protocols 
> configuration file. For example, to limit the number of ftp connections to 
> "ftp://ftp.foo.bar"; to 1, one would only have to add the following to 
> $KDEHOME/share/config/kio_ftprc:
> 
> [ftp.foo.bar]
> MaxInstancesPerHost=1
> 
> But that is not all. The user can make that restriction apply globally to all 
> ftp connections by simply moving property to the global section of of the 
> configuration file. That is move it out of the host ("[ftp.foo.bar]") 
> section. And to make it apply to every protocol, simply move the property to 
> the generic ioslave configuration file, $KDEHOME/share/config/kioslaverc.
> 
> 
> This addresses bug 64647.
> http://bugs.kde.org/show_bug.cgi?id=64647
> 
> 
> Diffs
> -
> 
>   kio/kio/scheduler.cpp 6b4ed52 
> 
> Diff: http://git.reviewboard.kde.org/r/104120/diff/
> 
> 
> Testing
> ---
> 
> To verify correct behavior, I added the following settings to kio_ftprc and 
> attempted to download multiple files at the same time. KIO::Scheduler 
> correctly processed the request one at a time:
> 
> [ftp.kde.org]
> MaxConnections=1
> 
> 
> Thanks,
> 
> Dawit Alemayehu
> 
>



Re: Review Request: Add cmake config for kdeclarative library.

2012-03-05 Thread Alexander Neundorf


> On March 2, 2012, 6:57 p.m., Laszlo Papp wrote:
> > I am a bit of layman in here (thus pardon me), but I would personally 
> > prefer a separated location for these config files. Something like either 
> > cmake/modules or in the experimental subfolder itself right next to the 
> > "CTestConfig.cmake" (I do not personally know what is the best practice 
> > here). You can see an example for cmake/modules from Stephen in grantlee, 
> > but the cmake example, about it, puts it into the $projectroot. Admittedly, 
> > it would be nice to hear some kde-buildsystem guy(s) to comment on this, 
> > like Alex, Stephen, etc. :)
> > 
> > Thank you for your effort about it really, by the way!

Do you mean the location when installed ?
This has to be ${LIB_INSTALL_DIR}/cmake/KDeclarative/ (ok, some small 
variations on this are also supported).

Alex


- Alexander


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104140/#review11090
---


On March 2, 2012, 6:01 p.m., Lamarque Vieira Souza wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104140/
> ---
> 
> (Updated March 2, 2012, 6:01 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Description
> ---
> 
> Currently kdeclarative library does not install the KDeclarativeConfig.cmake 
> and KDeclarativeConfigVersion.cmake to ${LIB_INSTALL_DIR}/cmake/KDeclarative 
> and so other KDE programs cannot find the library using cmake's find_package 
> macro.
> 
> kde-workspace, kde-runtime and plasma-mobile currently hardcode the 
> "kdeclarative" library name in their CMakeLists.txt, which is not ideal. Once 
> this patch is submitted we need to fix their CMakeLists.txt to use 
> "find_package(KDeclarative REQUIRED)".
> 
> 
> Diffs
> -
> 
>   experimental/libkdeclarative/CMakeLists.txt 0db647c 
>   experimental/libkdeclarative/KDeclarativeConfig.cmake.in PRE-CREATION 
>   experimental/libkdeclarative/KDeclarativeConfigVersion.cmake.in 
> PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/104140/diff/
> 
> 
> Testing
> ---
> 
> I can now compile kde-workspace/ksmserver without using the custom made 
> FindKDeclarative.cmake.
> 
> 
> Thanks,
> 
> Lamarque Vieira Souza
> 
>



Re: Review Request: Add cmake config for kdeclarative library.

2012-03-05 Thread Alexander Neundorf

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104140/#review11151
---



experimental/libkdeclarative/KDeclarativeConfig.cmake.in


You may want to use something like
KDeclarative_SOURCE_DIR, which is defined if there is a project call like
project(KDeclarative)
in the KDeclarative CMakeLists.txt. You could then also check whether this 
variable is actually set, and error out if not.



experimental/libkdeclarative/KDeclarativeConfig.cmake.in


I didn't check, but how is INCLUDE_INSTALL_DIR set ?
Is it done by via find_package(KDE4) ?
In this case, INCLUDE_INSTALL_DIR is a relative path under Windows, so the 
config file wouldn't work properly under Windows.


- Alexander Neundorf


On March 2, 2012, 6:01 p.m., Lamarque Vieira Souza wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104140/
> ---
> 
> (Updated March 2, 2012, 6:01 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Description
> ---
> 
> Currently kdeclarative library does not install the KDeclarativeConfig.cmake 
> and KDeclarativeConfigVersion.cmake to ${LIB_INSTALL_DIR}/cmake/KDeclarative 
> and so other KDE programs cannot find the library using cmake's find_package 
> macro.
> 
> kde-workspace, kde-runtime and plasma-mobile currently hardcode the 
> "kdeclarative" library name in their CMakeLists.txt, which is not ideal. Once 
> this patch is submitted we need to fix their CMakeLists.txt to use 
> "find_package(KDeclarative REQUIRED)".
> 
> 
> Diffs
> -
> 
>   experimental/libkdeclarative/CMakeLists.txt 0db647c 
>   experimental/libkdeclarative/KDeclarativeConfig.cmake.in PRE-CREATION 
>   experimental/libkdeclarative/KDeclarativeConfigVersion.cmake.in 
> PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/104140/diff/
> 
> 
> Testing
> ---
> 
> I can now compile kde-workspace/ksmserver without using the custom made 
> FindKDeclarative.cmake.
> 
> 
> Thanks,
> 
> Lamarque Vieira Souza
> 
>



Re: Review Request: Add cmake config for kdeclarative library.

2012-03-05 Thread Lamarque Vieira Souza


> On March 5, 2012, 8:51 p.m., Alexander Neundorf wrote:
> > experimental/libkdeclarative/KDeclarativeConfig.cmake.in, line 14
> > 
> >
> > I didn't check, but how is INCLUDE_INSTALL_DIR set ?
> > Is it done by via find_package(KDE4) ?
> > In this case, INCLUDE_INSTALL_DIR is a relative path under Windows, so 
> > the config file wouldn't work properly under Windows.

I do not know, INCLUDE_INSTALL_DIR was already used in 
libkdeclarative/CMakeLists.txt before I created this patch. I am just using it.


> On March 5, 2012, 8:51 p.m., Alexander Neundorf wrote:
> > experimental/libkdeclarative/KDeclarativeConfig.cmake.in, line 12
> > 
> >
> > You may want to use something like
> > KDeclarative_SOURCE_DIR, which is defined if there is a project call 
> > like
> > project(KDeclarative)
> > in the KDeclarative CMakeLists.txt. You could then also check whether 
> > this variable is actually set, and error out if not.

Both KDECLARATIVE_INCLUDE_DIRS and PROJECT_SOURCE_DIR contain the same value. 
What is the difference in using one or the other?


- Lamarque Vieira


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104140/#review11151
---


On March 2, 2012, 6:01 p.m., Lamarque Vieira Souza wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104140/
> ---
> 
> (Updated March 2, 2012, 6:01 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Description
> ---
> 
> Currently kdeclarative library does not install the KDeclarativeConfig.cmake 
> and KDeclarativeConfigVersion.cmake to ${LIB_INSTALL_DIR}/cmake/KDeclarative 
> and so other KDE programs cannot find the library using cmake's find_package 
> macro.
> 
> kde-workspace, kde-runtime and plasma-mobile currently hardcode the 
> "kdeclarative" library name in their CMakeLists.txt, which is not ideal. Once 
> this patch is submitted we need to fix their CMakeLists.txt to use 
> "find_package(KDeclarative REQUIRED)".
> 
> 
> Diffs
> -
> 
>   experimental/libkdeclarative/CMakeLists.txt 0db647c 
>   experimental/libkdeclarative/KDeclarativeConfig.cmake.in PRE-CREATION 
>   experimental/libkdeclarative/KDeclarativeConfigVersion.cmake.in 
> PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/104140/diff/
> 
> 
> Testing
> ---
> 
> I can now compile kde-workspace/ksmserver without using the custom made 
> FindKDeclarative.cmake.
> 
> 
> Thanks,
> 
> Lamarque Vieira Souza
> 
>



Re: Review Request: Add cmake config for kdeclarative library.

2012-03-05 Thread Lamarque Vieira Souza


> On March 2, 2012, 6:57 p.m., Laszlo Papp wrote:
> > I am a bit of layman in here (thus pardon me), but I would personally 
> > prefer a separated location for these config files. Something like either 
> > cmake/modules or in the experimental subfolder itself right next to the 
> > "CTestConfig.cmake" (I do not personally know what is the best practice 
> > here). You can see an example for cmake/modules from Stephen in grantlee, 
> > but the cmake example, about it, puts it into the $projectroot. Admittedly, 
> > it would be nice to hear some kde-buildsystem guy(s) to comment on this, 
> > like Alex, Stephen, etc. :)
> > 
> > Thank you for your effort about it really, by the way!
> 
> Alexander Neundorf wrote:
> Do you mean the location when installed ?
> This has to be ${LIB_INSTALL_DIR}/cmake/KDeclarative/ (ok, some small 
> variations on this are also supported).
> 
> Alex
>

I still do not get why use a different path than 
${LIB_INSTALL_DIR}/cmake/KDeclarative/. Just because the library is 
experimental? By the way, why is libkdeclarative still experimental? Device 
Notifier from kde-workspace 4.8.0 already depends on it. Shouldn't we upgrade 
libkdeclarative to stable?


- Lamarque Vieira


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104140/#review11090
---


On March 2, 2012, 6:01 p.m., Lamarque Vieira Souza wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104140/
> ---
> 
> (Updated March 2, 2012, 6:01 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Description
> ---
> 
> Currently kdeclarative library does not install the KDeclarativeConfig.cmake 
> and KDeclarativeConfigVersion.cmake to ${LIB_INSTALL_DIR}/cmake/KDeclarative 
> and so other KDE programs cannot find the library using cmake's find_package 
> macro.
> 
> kde-workspace, kde-runtime and plasma-mobile currently hardcode the 
> "kdeclarative" library name in their CMakeLists.txt, which is not ideal. Once 
> this patch is submitted we need to fix their CMakeLists.txt to use 
> "find_package(KDeclarative REQUIRED)".
> 
> 
> Diffs
> -
> 
>   experimental/libkdeclarative/CMakeLists.txt 0db647c 
>   experimental/libkdeclarative/KDeclarativeConfig.cmake.in PRE-CREATION 
>   experimental/libkdeclarative/KDeclarativeConfigVersion.cmake.in 
> PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/104140/diff/
> 
> 
> Testing
> ---
> 
> I can now compile kde-workspace/ksmserver without using the custom made 
> FindKDeclarative.cmake.
> 
> 
> Thanks,
> 
> Lamarque Vieira Souza
> 
>



Re: Review Request: Add cmake config for kdeclarative library.

2012-03-05 Thread Alexander Neundorf


> On March 5, 2012, 8:51 p.m., Alexander Neundorf wrote:
> > experimental/libkdeclarative/KDeclarativeConfig.cmake.in, line 12
> > 
> >
> > You may want to use something like
> > KDeclarative_SOURCE_DIR, which is defined if there is a project call 
> > like
> > project(KDeclarative)
> > in the KDeclarative CMakeLists.txt. You could then also check whether 
> > this variable is actually set, and error out if not.
> 
> Lamarque Vieira Souza wrote:
> Both KDECLARATIVE_INCLUDE_DIRS and PROJECT_SOURCE_DIR contain the same 
> value. What is the difference in using one or the other?

KDeclarative_SOURCE_DIR, not KDECLARATIVE_INCLUDE_DIRS.
KDeclarative_SOURCE_DIR is only set if you are inside the expected source tree 
(which should then contain a respective project() calls).


- Alexander


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104140/#review11151
---


On March 2, 2012, 6:01 p.m., Lamarque Vieira Souza wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104140/
> ---
> 
> (Updated March 2, 2012, 6:01 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Description
> ---
> 
> Currently kdeclarative library does not install the KDeclarativeConfig.cmake 
> and KDeclarativeConfigVersion.cmake to ${LIB_INSTALL_DIR}/cmake/KDeclarative 
> and so other KDE programs cannot find the library using cmake's find_package 
> macro.
> 
> kde-workspace, kde-runtime and plasma-mobile currently hardcode the 
> "kdeclarative" library name in their CMakeLists.txt, which is not ideal. Once 
> this patch is submitted we need to fix their CMakeLists.txt to use 
> "find_package(KDeclarative REQUIRED)".
> 
> 
> Diffs
> -
> 
>   experimental/libkdeclarative/CMakeLists.txt 0db647c 
>   experimental/libkdeclarative/KDeclarativeConfig.cmake.in PRE-CREATION 
>   experimental/libkdeclarative/KDeclarativeConfigVersion.cmake.in 
> PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/104140/diff/
> 
> 
> Testing
> ---
> 
> I can now compile kde-workspace/ksmserver without using the custom made 
> FindKDeclarative.cmake.
> 
> 
> Thanks,
> 
> Lamarque Vieira Souza
> 
>



Re: Review Request: Add cmake config for kdeclarative library.

2012-03-05 Thread Lamarque Vieira Souza

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

(Updated March 5, 2012, 9:55 p.m.)


Review request for kdelibs.


Changes
---

Add "set(KDECLARATIVE_FOUND true)" to satisfy macro_log_feature calls.


Description
---

Currently kdeclarative library does not install the KDeclarativeConfig.cmake 
and KDeclarativeConfigVersion.cmake to ${LIB_INSTALL_DIR}/cmake/KDeclarative 
and so other KDE programs cannot find the library using cmake's find_package 
macro.

kde-workspace, kde-runtime and plasma-mobile currently hardcode the 
"kdeclarative" library name in their CMakeLists.txt, which is not ideal. Once 
this patch is submitted we need to fix their CMakeLists.txt to use 
"find_package(KDeclarative REQUIRED)".


Diffs (updated)
-

  experimental/libkdeclarative/CMakeLists.txt 0db647c 
  experimental/libkdeclarative/KDeclarativeConfig.cmake.in PRE-CREATION 
  experimental/libkdeclarative/KDeclarativeConfigVersion.cmake.in PRE-CREATION 

Diff: http://git.reviewboard.kde.org/r/104140/diff/


Testing
---

I can now compile kde-workspace/ksmserver without using the custom made 
FindKDeclarative.cmake.


Thanks,

Lamarque Vieira Souza



Reactivate your KDE bugs.kde.org account before March 30th 2012

2012-03-05 Thread Tom Albers
Hi,

We have recently installed a new update of the bugzilla software and we would 
like to ask you to reactivate your accounts. This can be done in one simple 
step: login on the http://bugs.kde.org site.

If you don't reactivate your account before March 30th we will block your 
account from logging in until the password reset feature is used to set a new 
password.

Sorry for the trouble, but we hope you will enjoy the upgrade.

Best,

Tom Albers
KDE Sysadmin