D5556: build: Remove KService dependency

2017-04-23 Thread Palo Kisa
palokisa created this revision.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.

REVISION SUMMARY
  ..as it's not used anywhere (and the KService isn't some kind of
  "selfinitializing" library, that only needs to be linked to).

REPOSITORY
  R268 KGlobalAccel

REVISION DETAIL
  https://phabricator.kde.org/D5556

AFFECTED FILES
  CMakeLists.txt
  src/runtime/CMakeLists.txt

To: palokisa, graesslin, cfeck, apol
Cc: #frameworks


D5439: API dox: more info about KAboutData's orgDomain/desktopFileName properties

2017-04-23 Thread Andrius Štikonas
stikonas accepted this revision.

REPOSITORY
  R244 KCoreAddons

BRANCH
  improveKAboutDataAPIDox

REVISION DETAIL
  https://phabricator.kde.org/D5439

To: kossebau, #frameworks, aacid, mpyne, ltoscano, stikonas
Cc: dfaure


D5439: API dox: more info about KAboutData's orgDomain/desktopFileName properties

2017-04-23 Thread Luigi Toscano
ltoscano accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R244 KCoreAddons

BRANCH
  improveKAboutDataAPIDox

REVISION DETAIL
  https://phabricator.kde.org/D5439

To: kossebau, #frameworks, aacid, mpyne, ltoscano, stikonas
Cc: dfaure


D5439: API dox: more info about KAboutData's orgDomain/desktopFileName properties

2017-04-23 Thread Michael Pyne
mpyne accepted this revision.
mpyne added a comment.


  I think the API dox fixes are fine to go in.  We can add i18n-related 
warnings in a separate patch as you suggest.

REPOSITORY
  R244 KCoreAddons

REVISION DETAIL
  https://phabricator.kde.org/D5439

To: kossebau, #frameworks, aacid, mpyne, ltoscano, stikonas
Cc: dfaure


D5550: Fix property changes being missed immediately after an obejct is added

2017-04-23 Thread David Rosca
drosca created this revision.
Restricted Application added a project: Frameworks.

REVISION SUMMARY
  Fix race condition when property changes may be missed if the property
  is changed immediately after the object is created.
  The issue was that the connection to PropertyChanged signal was
  created only after interfacesAdded signal was fired, which may have
  already been too late.
  This fixes it with connecting to PropertyChanged signal on all paths
  in Manager::init().
  
  BUG: 377405

TEST PLAN
  Added test pass + old tests still pass

REPOSITORY
  R269 BluezQt

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D5550

AFFECTED FILES
  autotests/fakebluez/devicemanager.cpp
  autotests/fakebluez/devicemanager.h
  autotests/managertest.cpp
  autotests/managertest.h
  src/adapter_p.cpp
  src/device_p.cpp
  src/input.cpp
  src/input_p.h
  src/manager_p.cpp
  src/manager_p.h
  src/mediaplayer_p.cpp
  src/utils.cpp
  src/utils.h

To: drosca, #frameworks


Re: Review Request 130090: Fix incorrect definition of major(3)/minor(3) macros

2017-04-23 Thread Lamarque Souza


> On April 22, 2017, 10:27 a.m., Lamarque Souza wrote:
> > autotests/CMakeLists.txt, line 66
> > 
> >
> > CMake's developers recommend using else() instead of 
> > else(). The  part used to be required with cmake 
> > 2.6.x, that is not true with cmake 3.x that we use nowadays.
> 
> KJ Tsanaktsidis wrote:
> I'm not sure I understand here - elseif() needs to have the expression to 
> match to enter the elseif() block? In any case I've gone ahead and deleted 
> this because I worked out a cleaner way to do this using cmake generator 
> expressions.

Oh sorry, I did a mistake. I thought it wase a else(). The expression is 
required for elseif(), the old code was correct. You can revert to the old 
code, which require less lines of code. Sorry again.


- Lamarque


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


On April 23, 2017, 9:56 a.m., KJ Tsanaktsidis wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130090/
> ---
> 
> (Updated April 23, 2017, 9:56 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: solid
> 
> 
> Description
> ---
> 
> Previously, udesksblock.cpp was attempting to find a definition for
> major/minor on Linux in  by checking Q_OS_LINUX before
> importing the header. Q_OS_LINUX is however only set when
> qsystemdetection.h is included, and the macro was being checked first.
> 
> Even had this check worked, it would still be wrong. On a modern version
> of the userspace linux-headers,  includes definitions for
> major and minor that assume each is limited to 8 bits and that dev_t is
> 16 bits. This is no longer true anymore; on Linux, major numbers can be
> up to 12 bits at present and minor numbers up to 20. Calling these
> macros with dev_t values > 2^16 would give incorrect results.
> 
> Because the Q_OS_LINUX check failed, a fallback version of the macros
> were defined for use on all platforms. The code is allegedly copied from
> kdev_t.h, except it is copied from the *kernel* version of the header,
> not the userspace version. Linux internally uses a different
> representation of dev_t than it exposes to userspace - the kernelspace
> version is 20 bits of minor/12 bits of major contiguously, but the
> userspace version packs the bits in a different order to maintain
> compatability with old 16-bit device numbers. Thus, this code also does
> not work for dev_t values > 2^16.
> 
> To fix this, we add CMake rules to search for a system-provided
> definition of the major/minor macros - on various systems, these can be
> in a few different places. As a fallback, we assume old-style 16-bit
> dev_t (although I suspect that is only used for Windows, where
> major/minor numbers are pretty meaningless anyway).
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 54adeea62b954b9169b37f1eab8fa3e215fafafa 
>   autotests/fakeUdisks2.h PRE-CREATION 
>   autotests/fakeUdisks2.cpp PRE-CREATION 
>   autotests/solidudisks2test.cpp PRE-CREATION 
>   src/solid/devices/backends/udisks2/CMakeLists.txt 
> 34390064af29ace07cbb3470945be098cc606d04 
>   src/solid/devices/backends/udisks2/udisksblock.cpp 
> 0622ec77fcf670a2005d34b7a6c31ca8b53a18d8 
> 
> Diff: https://git.reviewboard.kde.org/r/130090/diff/
> 
> 
> Testing
> ---
> 
> I've written a little snippet to iterate through block devices, print their 
> major/minor number, and their device properties. It was previously 
> incorrectly labeling all my disks with major 0 and minor == device_number 
> (since it was using the first 20 bits for the minor). It now correctly 
> identifies their major/minor number.
> 
> 
> Thanks,
> 
> KJ Tsanaktsidis
> 
>



Re: Review Request 130090: Fix incorrect definition of major(3)/minor(3) macros

2017-04-23 Thread KJ Tsanaktsidis


> On April 22, 2017, 10:27 a.m., Lamarque Souza wrote:
> > autotests/CMakeLists.txt, line 66
> > 
> >
> > CMake's developers recommend using else() instead of 
> > else(). The  part used to be required with cmake 
> > 2.6.x, that is not true with cmake 3.x that we use nowadays.

I'm not sure I understand here - elseif() needs to have the expression to match 
to enter the elseif() block? In any case I've gone ahead and deleted this 
because I worked out a cleaner way to do this using cmake generator expressions.


- KJ


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


On April 23, 2017, 9:56 a.m., KJ Tsanaktsidis wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130090/
> ---
> 
> (Updated April 23, 2017, 9:56 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: solid
> 
> 
> Description
> ---
> 
> Previously, udesksblock.cpp was attempting to find a definition for
> major/minor on Linux in  by checking Q_OS_LINUX before
> importing the header. Q_OS_LINUX is however only set when
> qsystemdetection.h is included, and the macro was being checked first.
> 
> Even had this check worked, it would still be wrong. On a modern version
> of the userspace linux-headers,  includes definitions for
> major and minor that assume each is limited to 8 bits and that dev_t is
> 16 bits. This is no longer true anymore; on Linux, major numbers can be
> up to 12 bits at present and minor numbers up to 20. Calling these
> macros with dev_t values > 2^16 would give incorrect results.
> 
> Because the Q_OS_LINUX check failed, a fallback version of the macros
> were defined for use on all platforms. The code is allegedly copied from
> kdev_t.h, except it is copied from the *kernel* version of the header,
> not the userspace version. Linux internally uses a different
> representation of dev_t than it exposes to userspace - the kernelspace
> version is 20 bits of minor/12 bits of major contiguously, but the
> userspace version packs the bits in a different order to maintain
> compatability with old 16-bit device numbers. Thus, this code also does
> not work for dev_t values > 2^16.
> 
> To fix this, we add CMake rules to search for a system-provided
> definition of the major/minor macros - on various systems, these can be
> in a few different places. As a fallback, we assume old-style 16-bit
> dev_t (although I suspect that is only used for Windows, where
> major/minor numbers are pretty meaningless anyway).
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 54adeea62b954b9169b37f1eab8fa3e215fafafa 
>   autotests/fakeUdisks2.h PRE-CREATION 
>   autotests/fakeUdisks2.cpp PRE-CREATION 
>   autotests/solidudisks2test.cpp PRE-CREATION 
>   src/solid/devices/backends/udisks2/CMakeLists.txt 
> 34390064af29ace07cbb3470945be098cc606d04 
>   src/solid/devices/backends/udisks2/udisksblock.cpp 
> 0622ec77fcf670a2005d34b7a6c31ca8b53a18d8 
> 
> Diff: https://git.reviewboard.kde.org/r/130090/diff/
> 
> 
> Testing
> ---
> 
> I've written a little snippet to iterate through block devices, print their 
> major/minor number, and their device properties. It was previously 
> incorrectly labeling all my disks with major 0 and minor == device_number 
> (since it was using the first 20 bits for the minor). It now correctly 
> identifies their major/minor number.
> 
> 
> Thanks,
> 
> KJ Tsanaktsidis
> 
>



Re: Review Request 130090: Fix incorrect definition of major(3)/minor(3) macros

2017-04-23 Thread KJ Tsanaktsidis

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

(Updated April 23, 2017, 9:56 a.m.)


Review request for KDE Frameworks.


Changes
---

* Fix definition style of const-returning functions
* Replace if()..elseif()...else() CMake macros with a clearer control flow


Repository: solid


Description
---

Previously, udesksblock.cpp was attempting to find a definition for
major/minor on Linux in  by checking Q_OS_LINUX before
importing the header. Q_OS_LINUX is however only set when
qsystemdetection.h is included, and the macro was being checked first.

Even had this check worked, it would still be wrong. On a modern version
of the userspace linux-headers,  includes definitions for
major and minor that assume each is limited to 8 bits and that dev_t is
16 bits. This is no longer true anymore; on Linux, major numbers can be
up to 12 bits at present and minor numbers up to 20. Calling these
macros with dev_t values > 2^16 would give incorrect results.

Because the Q_OS_LINUX check failed, a fallback version of the macros
were defined for use on all platforms. The code is allegedly copied from
kdev_t.h, except it is copied from the *kernel* version of the header,
not the userspace version. Linux internally uses a different
representation of dev_t than it exposes to userspace - the kernelspace
version is 20 bits of minor/12 bits of major contiguously, but the
userspace version packs the bits in a different order to maintain
compatability with old 16-bit device numbers. Thus, this code also does
not work for dev_t values > 2^16.

To fix this, we add CMake rules to search for a system-provided
definition of the major/minor macros - on various systems, these can be
in a few different places. As a fallback, we assume old-style 16-bit
dev_t (although I suspect that is only used for Windows, where
major/minor numbers are pretty meaningless anyway).


Diffs (updated)
-

  autotests/CMakeLists.txt 54adeea62b954b9169b37f1eab8fa3e215fafafa 
  autotests/fakeUdisks2.h PRE-CREATION 
  autotests/fakeUdisks2.cpp PRE-CREATION 
  autotests/solidudisks2test.cpp PRE-CREATION 
  src/solid/devices/backends/udisks2/CMakeLists.txt 
34390064af29ace07cbb3470945be098cc606d04 
  src/solid/devices/backends/udisks2/udisksblock.cpp 
0622ec77fcf670a2005d34b7a6c31ca8b53a18d8 

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


Testing
---

I've written a little snippet to iterate through block devices, print their 
major/minor number, and their device properties. It was previously incorrectly 
labeling all my disks with major 0 and minor == device_number (since it was 
using the first 20 bits for the minor). It now correctly identifies their 
major/minor number.


Thanks,

KJ Tsanaktsidis



Re: Review Request 130069: Reproducible builds: drop version from XMLGUI_COMPILING_OS

2017-04-23 Thread Maximiliano Curia

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

(Updated April 23, 2017, 7:50 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit 0570614d56712139fb7af90b92c31a32177b72f5 by Maximiliano 
Curia to branch master.


Repository: kxmlgui


Description
---

This is a fix for the Debian bug: https://bugs.debian.org/835053. The
reproducible build team found kxmlgui not reproducible by the use of
the CMAKE_SYSTEM variable. Changing it to CMAKE_SYSTEM_NAME still gives
us information about the SYSTEM, disregarding the kernel version.


Diffs
-

  src/config-xmlgui.h.cmake 9d7f3dcf3ba49f94c211afb6d054d8de6044b370 

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


Testing
---


Thanks,

Maximiliano Curia