Re: CMake kauth_install_* with system kauth and user CMAKE_INSTALL_PREFIX

2020-10-19 Thread Christophe Giboudeaux
On lundi 19 octobre 2020 12:30:59 CEST Milian Wolff wrote:
> On Montag, 19. Oktober 2020 11:27:29 CEST Harald Sitter wrote:
> > Yo
> > 
> > On 18.10.20 10:11, Milian Wolff wrote:
> > > Hey all,
> > > 
> > > since some time now I'm only compiling parts of KF5 selectively into a
> > > custom prefix. Most notably, I'm only interested in ktexteditor and
> > > syntax- highlighting, and would like to obtain all other frameworks
> > > through my distribution packages.
> > > 
> > > Sadly, this doesn't work as easily, as ktexteditor is trying to do this:
> > > 
> > > ```
> > > install(TARGETS kauth_ktexteditor_helper DESTINATION $
> > > {KAUTH_HELPER_INSTALL_DIR} )
> > > kauth_install_helper_files(kauth_ktexteditor_helper
> > > org.kde.ktexteditor.katetextbuffer root)
> > > kauth_install_actions(org.kde.ktexteditor.katetextbuffer buffer/
> > > org.kde.ktexteditor.katetextbuffer.actions)
> > > ```
> > > 
> > > Because my KAuth is a system-provided installation, and KTextEditor
> > > should
> > > be installed into a user-writable prefix, I get this error on `ninja
> > > install`:
> > > 
> > > ```
> > > 
> > > CMake Error at src/cmake_install.cmake:143 (file):
> > >   file INSTALL cannot copy file
> > >   "/home/milian/projects/kf5/build/frameworks/ktexteditor/src/
> > > 
> > > org.kde.ktexteditor.katetextbuffer.policy"
> > > 
> > >   to
> > >   "/usr/share/polkit-1/actions/org.kde.ktexteditor.katetextbuffer.policy
> > >   "
> > >   
> > >   Permission denied.
> > > 
> > > Call Stack (most recent call first):
> > >   cmake_install.cmake:77 (include)
> > > 
> > > ```
> > > 
> > > I can workaround this by either commenting out the kauth install bits in
> > > ktexteditor or by installing kauth seperately too. But both are in my
> > > opinion not ideal.
> > > 
> > > I don't think it's currently possible to overwrite the KAuth install
> > > directory at cmake configure time. I would like to change that, unless
> > > there is something I'm missing which would prevent this? I am hoping
> > > that
> > > any folder works as long as it's listed in the `XDG_DATA_DIRS` env var -
> > > can someone confirm this?
> > 
> > Alas, the path is hardcoded at buildtime from what I see:
> > https://gitlab.freedesktop.org/polkit/polkit/-/blob/master/src/polkitbacke
> > nd /polkitbackendinteractiveauthority.c#L302
> > 
> > Relevant: https://bugs.kde.org/show_bug.cgi?id=425272
> 
> So the path that needs to be used is actually the polkit path? Meaning the
> question where KAuth is being installed to doesn't really matter? That would
> imply that KAuth is broken anyways when it's not installed to the same
> prefix that polkit is being installed to, no?
> 
Yes. Polkit is a security tool, it doesn't allow reading files in random 
locations.

> If so, then it's just one more reason to be able to skip kauth policy
> installation, as they won't be picked up anyways...

kauth can be configured with -DKAUTH_BACKEND_NAME=FAKE






Re: CMake kauth_install_* with system kauth and user CMAKE_INSTALL_PREFIX

2020-10-19 Thread Ingo Klöcker
On Montag, 19. Oktober 2020 17:22:22 CEST Milian Wolff wrote:
> On Montag, 19. Oktober 2020 17:21:28 CEST Harald Sitter wrote:
> > I'm not sure it's a good idea, but we could treat this like
> > KDE_INSTALL_USE_QT_SYS_PATHS. By default we'll simply install to
> > $CMAKE_PREFIX/share/polkit-1/actions/ unless explicitly configured with
> > KDE_INSTALL_USE_POLKIT_PATHS in which case we'll use whatever polkit uses.
> > What sets this apart from qt_syspath of course is that not using the
> > polkit path basically never makes sense as it'd be broken. So maybe the
> > default state should be ON and when one is sure that polkit isn't needed
> > one could turn it OFF.
> 
> Installing something that's never going to be used - why? I would much
> rather prefer making it explicit by saying:
> 
> Either you install it to the correct path, or you don't install it at all.

FWIW, for a very similar problem (udev rules instead of polkit rules) bluez-qt 
has the CMAKE flag INSTALL_UDEV_RULE to disable installation of udev rules.

If have this in my .kdesrc-buildrc:
=
options bluez-qt
cmake-options -DINSTALL_UDEV_RULE=0
end options
=

So, maybe add a KDE_INSTALL_POLKIT_RULE[S] (or ..._ACTION[S]) flag to allow 
disabling the installation of polkit stuff.

Regards,
Ingo


signature.asc
Description: This is a digitally signed message part.


Re: CMake kauth_install_* with system kauth and user CMAKE_INSTALL_PREFIX

2020-10-19 Thread Milian Wolff
On Montag, 19. Oktober 2020 17:21:28 CEST Harald Sitter wrote:
> On 19.10.20 17:06, Milian Wolff wrote:
> > On Montag, 19. Oktober 2020 16:56:27 CEST Harald Sitter wrote:
> >> On 19.10.20 12:30, Milian Wolff wrote:
> >>> On Montag, 19. Oktober 2020 11:27:29 CEST Harald Sitter wrote:
>  Yo
>  
>  On 18.10.20 10:11, Milian Wolff wrote:
> > Hey all,
> > 
> > since some time now I'm only compiling parts of KF5 selectively into a
> > custom prefix. Most notably, I'm only interested in ktexteditor and
> > syntax- highlighting, and would like to obtain all other frameworks
> > through my distribution packages.
> > 
> > Sadly, this doesn't work as easily, as ktexteditor is trying to do
> > this:
> > 
> > ```
> > install(TARGETS kauth_ktexteditor_helper DESTINATION $
> > {KAUTH_HELPER_INSTALL_DIR} )
> > kauth_install_helper_files(kauth_ktexteditor_helper
> > org.kde.ktexteditor.katetextbuffer root)
> > kauth_install_actions(org.kde.ktexteditor.katetextbuffer buffer/
> > org.kde.ktexteditor.katetextbuffer.actions)
> > ```
> > 
> > Because my KAuth is a system-provided installation, and KTextEditor
> > should
> > be installed into a user-writable prefix, I get this error on `ninja
> > install`:
> > 
> > ```
> > 
> > CMake Error at src/cmake_install.cmake:143 (file):
> >   file INSTALL cannot copy file
> >   "/home/milian/projects/kf5/build/frameworks/ktexteditor/src/
> > 
> > org.kde.ktexteditor.katetextbuffer.policy"
> > 
> >   to
> >   "/usr/share/polkit-1/actions/org.kde.ktexteditor.katetextbuffer.poli
> >   cy
> >   "
> >   
> >   Permission denied.
> > 
> > Call Stack (most recent call first):
> >   cmake_install.cmake:77 (include)
> > 
> > ```
> > 
> > I can workaround this by either commenting out the kauth install bits
> > in
> > ktexteditor or by installing kauth seperately too. But both are in my
> > opinion not ideal.
> > 
> > I don't think it's currently possible to overwrite the KAuth install
> > directory at cmake configure time. I would like to change that, unless
> > there is something I'm missing which would prevent this? I am hoping
> > that
> > any folder works as long as it's listed in the `XDG_DATA_DIRS` env var
> > -
> > can someone confirm this?
>  
>  Alas, the path is hardcoded at buildtime from what I see:
>  https://gitlab.freedesktop.org/polkit/polkit/-/blob/master/src/polkitba
>  ck
>  end /polkitbackendinteractiveauthority.c#L302
>  
>  Relevant: https://bugs.kde.org/show_bug.cgi?id=425272
> >>> 
> >>> So the path that needs to be used is actually the polkit path?
> >> 
> >> That's my understanding of the code, yes.
> >> 
> >>> Meaning the
> >>> question where KAuth is being installed to doesn't really matter? That
> >>> would imply that KAuth is broken anyways when it's not installed to the
> >>> same prefix that polkit is being installed to, no?
> >> 
> >> Nope. If the policy was installed to a different path it would be
> >> broken, but the very error you posted is because kauth is insisting on
> >> putting the policy in the correct path rather than the prefix the rest
> >> of the build is installing to.
> > 
> > No, it's using the install location of kauth, it doesn't query polkit
> > itself. I.e. if I hand-compile KAuth and install into a custom prefix,
> > then I will have:
> > 
> > ```
> > $ grep INSTALL /home/milian/projects/compiled/kf5-dbg/lib/cmake/KF5Auth/
> > KF5AuthConfig.cmake
> > set(KAUTH_POLICY_FILES_INSTALL_DIR
> > "/home/milian/projects/compiled/kf5/share/ polkit-1/actions")
> > set(KAUTH_HELPER_INSTALL_DIR "lib/libexec/kauth")
> > set(KAUTH_HELPER_INSTALL_ABSOLUTE_DIR
> > "/home/milian/projects/compiled/kf5/lib/ libexec/kauth")
> > ```
> 
> Ohh! This is indeed plain silly. I had thought it would use the value
> from pkgconfig :S
> 
> > Now I can happily compile e.g. ktexteditor against this, but it would be
> > just as broken as the polkit files it installed will never be found
> > anyways.
> > 
> > So, I guess there are two things to solve here:
> > 
> > a) make it easy to opt-out / disable kauth polkit file installation via a
> > cache var in the `kauth_install_*` cmake macros, such that I can just
> > disable that when building ktexteditor.
> 
> I'm not sure it's a good idea, but we could treat this like
> KDE_INSTALL_USE_QT_SYS_PATHS. By default we'll simply install to
> $CMAKE_PREFIX/share/polkit-1/actions/ unless explicitly configured with
> KDE_INSTALL_USE_POLKIT_PATHS in which case we'll use whatever polkit uses.
> What sets this apart from qt_syspath of course is that not using the
> polkit path basically never makes sense as it'd be broken. So maybe the
> default state should be ON and when one is sure that polkit isn't needed
> one could turn it OFF.

Installing something that's never going to be 

Re: CMake kauth_install_* with system kauth and user CMAKE_INSTALL_PREFIX

2020-10-19 Thread Harald Sitter
On 19.10.20 17:06, Milian Wolff wrote:
> On Montag, 19. Oktober 2020 16:56:27 CEST Harald Sitter wrote:
>> On 19.10.20 12:30, Milian Wolff wrote:
>>> On Montag, 19. Oktober 2020 11:27:29 CEST Harald Sitter wrote:
 Yo

 On 18.10.20 10:11, Milian Wolff wrote:
> Hey all,
>
> since some time now I'm only compiling parts of KF5 selectively into a
> custom prefix. Most notably, I'm only interested in ktexteditor and
> syntax- highlighting, and would like to obtain all other frameworks
> through my distribution packages.
>
> Sadly, this doesn't work as easily, as ktexteditor is trying to do this:
>
> ```
> install(TARGETS kauth_ktexteditor_helper DESTINATION $
> {KAUTH_HELPER_INSTALL_DIR} )
> kauth_install_helper_files(kauth_ktexteditor_helper
> org.kde.ktexteditor.katetextbuffer root)
> kauth_install_actions(org.kde.ktexteditor.katetextbuffer buffer/
> org.kde.ktexteditor.katetextbuffer.actions)
> ```
>
> Because my KAuth is a system-provided installation, and KTextEditor
> should
> be installed into a user-writable prefix, I get this error on `ninja
> install`:
>
> ```
>
> CMake Error at src/cmake_install.cmake:143 (file):
>   file INSTALL cannot copy file
>   "/home/milian/projects/kf5/build/frameworks/ktexteditor/src/
>
> org.kde.ktexteditor.katetextbuffer.policy"
>
>   to
>   "/usr/share/polkit-1/actions/org.kde.ktexteditor.katetextbuffer.policy
>   "
>   
>   Permission denied.
>
> Call Stack (most recent call first):
>   cmake_install.cmake:77 (include)
>
> ```
>
> I can workaround this by either commenting out the kauth install bits in
> ktexteditor or by installing kauth seperately too. But both are in my
> opinion not ideal.
>
> I don't think it's currently possible to overwrite the KAuth install
> directory at cmake configure time. I would like to change that, unless
> there is something I'm missing which would prevent this? I am hoping
> that
> any folder works as long as it's listed in the `XDG_DATA_DIRS` env var -
> can someone confirm this?

 Alas, the path is hardcoded at buildtime from what I see:
 https://gitlab.freedesktop.org/polkit/polkit/-/blob/master/src/polkitback
 end /polkitbackendinteractiveauthority.c#L302

 Relevant: https://bugs.kde.org/show_bug.cgi?id=425272
>>>
>>> So the path that needs to be used is actually the polkit path?
>>
>> That's my understanding of the code, yes.
>>
>>> Meaning the
>>> question where KAuth is being installed to doesn't really matter? That
>>> would imply that KAuth is broken anyways when it's not installed to the
>>> same prefix that polkit is being installed to, no?
>>
>> Nope. If the policy was installed to a different path it would be
>> broken, but the very error you posted is because kauth is insisting on
>> putting the policy in the correct path rather than the prefix the rest
>> of the build is installing to.
> 
> No, it's using the install location of kauth, it doesn't query polkit itself. 
> I.e. if I hand-compile KAuth and install into a custom prefix, then I will 
> have:
> 
> ```
> $ grep INSTALL /home/milian/projects/compiled/kf5-dbg/lib/cmake/KF5Auth/
> KF5AuthConfig.cmake
> set(KAUTH_POLICY_FILES_INSTALL_DIR "/home/milian/projects/compiled/kf5/share/
> polkit-1/actions")
> set(KAUTH_HELPER_INSTALL_DIR "lib/libexec/kauth")
> set(KAUTH_HELPER_INSTALL_ABSOLUTE_DIR "/home/milian/projects/compiled/kf5/lib/
> libexec/kauth")
> ```

Ohh! This is indeed plain silly. I had thought it would use the value
from pkgconfig :S

> Now I can happily compile e.g. ktexteditor against this, but it would be just 
> as broken as the polkit files it installed will never be found anyways.
> 
> So, I guess there are two things to solve here:
> 
> a) make it easy to opt-out / disable kauth polkit file installation via a 
> cache var in the `kauth_install_*` cmake macros, such that I can just disable 
> that when building ktexteditor.

I'm not sure it's a good idea, but we could treat this like
KDE_INSTALL_USE_QT_SYS_PATHS. By default we'll simply install to
$CMAKE_PREFIX/share/polkit-1/actions/ unless explicitly configured with
KDE_INSTALL_USE_POLKIT_PATHS in which case we'll use whatever polkit uses.
What sets this apart from qt_syspath of course is that not using the
polkit path basically never makes sense as it'd be broken. So maybe the
default state should be ON and when one is sure that polkit isn't needed
one could turn it OFF.

> b) find a way to query polkit for the right path to use and use that by 
> default instead of the kauth install prefix.

polkit-gobject-1's pkgconfig encodes the path. So that's easy.

HS



signature.asc
Description: OpenPGP digital signature


Re: CMake kauth_install_* with system kauth and user CMAKE_INSTALL_PREFIX

2020-10-19 Thread Milian Wolff
On Montag, 19. Oktober 2020 13:33:38 CEST Christophe Giboudeaux wrote:
> On lundi 19 octobre 2020 12:30:59 CEST Milian Wolff wrote:
> > On Montag, 19. Oktober 2020 11:27:29 CEST Harald Sitter wrote:
> > > Yo
> > > 
> > > On 18.10.20 10:11, Milian Wolff wrote:
> > > > Hey all,
> > > > 
> > > > since some time now I'm only compiling parts of KF5 selectively into a
> > > > custom prefix. Most notably, I'm only interested in ktexteditor and
> > > > syntax- highlighting, and would like to obtain all other frameworks
> > > > through my distribution packages.
> > > > 
> > > > Sadly, this doesn't work as easily, as ktexteditor is trying to do
> > > > this:
> > > > 
> > > > ```
> > > > install(TARGETS kauth_ktexteditor_helper DESTINATION $
> > > > {KAUTH_HELPER_INSTALL_DIR} )
> > > > kauth_install_helper_files(kauth_ktexteditor_helper
> > > > org.kde.ktexteditor.katetextbuffer root)
> > > > kauth_install_actions(org.kde.ktexteditor.katetextbuffer buffer/
> > > > org.kde.ktexteditor.katetextbuffer.actions)
> > > > ```
> > > > 
> > > > Because my KAuth is a system-provided installation, and KTextEditor
> > > > should
> > > > be installed into a user-writable prefix, I get this error on `ninja
> > > > install`:
> > > > 
> > > > ```
> > > > 
> > > > CMake Error at src/cmake_install.cmake:143 (file):
> > > >   file INSTALL cannot copy file
> > > >   "/home/milian/projects/kf5/build/frameworks/ktexteditor/src/
> > > > 
> > > > org.kde.ktexteditor.katetextbuffer.policy"
> > > > 
> > > >   to
> > > >   "/usr/share/polkit-1/actions/org.kde.ktexteditor.katetextbuffer.poli
> > > >   cy
> > > >   "
> > > >   
> > > >   Permission denied.
> > > > 
> > > > Call Stack (most recent call first):
> > > >   cmake_install.cmake:77 (include)
> > > > 
> > > > ```
> > > > 
> > > > I can workaround this by either commenting out the kauth install bits
> > > > in
> > > > ktexteditor or by installing kauth seperately too. But both are in my
> > > > opinion not ideal.
> > > > 
> > > > I don't think it's currently possible to overwrite the KAuth install
> > > > directory at cmake configure time. I would like to change that, unless
> > > > there is something I'm missing which would prevent this? I am hoping
> > > > that
> > > > any folder works as long as it's listed in the `XDG_DATA_DIRS` env var
> > > > -
> > > > can someone confirm this?
> > > 
> > > Alas, the path is hardcoded at buildtime from what I see:
> > > https://gitlab.freedesktop.org/polkit/polkit/-/blob/master/src/polkitbac
> > > ke
> > > nd /polkitbackendinteractiveauthority.c#L302
> > > 
> > > Relevant: https://bugs.kde.org/show_bug.cgi?id=425272
> > 
> > So the path that needs to be used is actually the polkit path? Meaning the
> > question where KAuth is being installed to doesn't really matter? That
> > would imply that KAuth is broken anyways when it's not installed to the
> > same prefix that polkit is being installed to, no?
> 
> Yes. Polkit is a security tool, it doesn't allow reading files in random
> locations.

Sure, I understand this reasoning. But I don't get how one is supposed to use 
it then as a developer - I don't want to overwrite the polkit files that got 
installed through my package manager e.g.

> > If so, then it's just one more reason to be able to skip kauth policy
> > installation, as they won't be picked up anyways...
> 
> kauth can be configured with -DKAUTH_BACKEND_NAME=FAKE

I don't want to build kauth, I want to build ktexteditor, so this is where I'd 
like to disable the polkit installation. But ideally that should be generic 
and applicable to all users of KAuth - I'll prepare a patch for KAuth to get a 
cmake cache var added that can be used for this purpose then.

Cheers

-- 
Milian Wolff
m...@milianw.de
http://milianw.de

signature.asc
Description: This is a digitally signed message part.


Re: CMake kauth_install_* with system kauth and user CMAKE_INSTALL_PREFIX

2020-10-19 Thread Milian Wolff
On Montag, 19. Oktober 2020 16:56:27 CEST Harald Sitter wrote:
> On 19.10.20 12:30, Milian Wolff wrote:
> > On Montag, 19. Oktober 2020 11:27:29 CEST Harald Sitter wrote:
> >> Yo
> >> 
> >> On 18.10.20 10:11, Milian Wolff wrote:
> >>> Hey all,
> >>> 
> >>> since some time now I'm only compiling parts of KF5 selectively into a
> >>> custom prefix. Most notably, I'm only interested in ktexteditor and
> >>> syntax- highlighting, and would like to obtain all other frameworks
> >>> through my distribution packages.
> >>> 
> >>> Sadly, this doesn't work as easily, as ktexteditor is trying to do this:
> >>> 
> >>> ```
> >>> install(TARGETS kauth_ktexteditor_helper DESTINATION $
> >>> {KAUTH_HELPER_INSTALL_DIR} )
> >>> kauth_install_helper_files(kauth_ktexteditor_helper
> >>> org.kde.ktexteditor.katetextbuffer root)
> >>> kauth_install_actions(org.kde.ktexteditor.katetextbuffer buffer/
> >>> org.kde.ktexteditor.katetextbuffer.actions)
> >>> ```
> >>> 
> >>> Because my KAuth is a system-provided installation, and KTextEditor
> >>> should
> >>> be installed into a user-writable prefix, I get this error on `ninja
> >>> install`:
> >>> 
> >>> ```
> >>> 
> >>> CMake Error at src/cmake_install.cmake:143 (file):
> >>>   file INSTALL cannot copy file
> >>>   "/home/milian/projects/kf5/build/frameworks/ktexteditor/src/
> >>> 
> >>> org.kde.ktexteditor.katetextbuffer.policy"
> >>> 
> >>>   to
> >>>   "/usr/share/polkit-1/actions/org.kde.ktexteditor.katetextbuffer.policy
> >>>   "
> >>>   
> >>>   Permission denied.
> >>> 
> >>> Call Stack (most recent call first):
> >>>   cmake_install.cmake:77 (include)
> >>> 
> >>> ```
> >>> 
> >>> I can workaround this by either commenting out the kauth install bits in
> >>> ktexteditor or by installing kauth seperately too. But both are in my
> >>> opinion not ideal.
> >>> 
> >>> I don't think it's currently possible to overwrite the KAuth install
> >>> directory at cmake configure time. I would like to change that, unless
> >>> there is something I'm missing which would prevent this? I am hoping
> >>> that
> >>> any folder works as long as it's listed in the `XDG_DATA_DIRS` env var -
> >>> can someone confirm this?
> >> 
> >> Alas, the path is hardcoded at buildtime from what I see:
> >> https://gitlab.freedesktop.org/polkit/polkit/-/blob/master/src/polkitback
> >> end /polkitbackendinteractiveauthority.c#L302
> >> 
> >> Relevant: https://bugs.kde.org/show_bug.cgi?id=425272
> > 
> > So the path that needs to be used is actually the polkit path?
> 
> That's my understanding of the code, yes.
>
> > Meaning the
> > question where KAuth is being installed to doesn't really matter? That
> > would imply that KAuth is broken anyways when it's not installed to the
> > same prefix that polkit is being installed to, no?
> 
> Nope. If the policy was installed to a different path it would be
> broken, but the very error you posted is because kauth is insisting on
> putting the policy in the correct path rather than the prefix the rest
> of the build is installing to.

No, it's using the install location of kauth, it doesn't query polkit itself. 
I.e. if I hand-compile KAuth and install into a custom prefix, then I will 
have:

```
$ grep INSTALL /home/milian/projects/compiled/kf5-dbg/lib/cmake/KF5Auth/
KF5AuthConfig.cmake
set(KAUTH_POLICY_FILES_INSTALL_DIR "/home/milian/projects/compiled/kf5/share/
polkit-1/actions")
set(KAUTH_HELPER_INSTALL_DIR "lib/libexec/kauth")
set(KAUTH_HELPER_INSTALL_ABSOLUTE_DIR "/home/milian/projects/compiled/kf5/lib/
libexec/kauth")
```

Now I can happily compile e.g. ktexteditor against this, but it would be just 
as broken as the polkit files it installed will never be found anyways.

So, I guess there are two things to solve here:

a) make it easy to opt-out / disable kauth polkit file installation via a 
cache var in the `kauth_install_*` cmake macros, such that I can just disable 
that when building ktexteditor.

b) find a way to query polkit for the right path to use and use that by 
default instead of the kauth install prefix.

Or?
-- 
Milian Wolff
m...@milianw.de
http://milianw.de

signature.asc
Description: This is a digitally signed message part.


Re: CMake kauth_install_* with system kauth and user CMAKE_INSTALL_PREFIX

2020-10-19 Thread Harald Sitter
On 19.10.20 12:30, Milian Wolff wrote:
> On Montag, 19. Oktober 2020 11:27:29 CEST Harald Sitter wrote:
>> Yo
>>
>> On 18.10.20 10:11, Milian Wolff wrote:
>>> Hey all,
>>>
>>> since some time now I'm only compiling parts of KF5 selectively into a
>>> custom prefix. Most notably, I'm only interested in ktexteditor and
>>> syntax- highlighting, and would like to obtain all other frameworks
>>> through my distribution packages.
>>>
>>> Sadly, this doesn't work as easily, as ktexteditor is trying to do this:
>>>
>>> ```
>>> install(TARGETS kauth_ktexteditor_helper DESTINATION $
>>> {KAUTH_HELPER_INSTALL_DIR} )
>>> kauth_install_helper_files(kauth_ktexteditor_helper
>>> org.kde.ktexteditor.katetextbuffer root)
>>> kauth_install_actions(org.kde.ktexteditor.katetextbuffer buffer/
>>> org.kde.ktexteditor.katetextbuffer.actions)
>>> ```
>>>
>>> Because my KAuth is a system-provided installation, and KTextEditor should
>>> be installed into a user-writable prefix, I get this error on `ninja
>>> install`:
>>>
>>> ```
>>>
>>> CMake Error at src/cmake_install.cmake:143 (file):
>>>   file INSTALL cannot copy file
>>>   "/home/milian/projects/kf5/build/frameworks/ktexteditor/src/
>>>
>>> org.kde.ktexteditor.katetextbuffer.policy"
>>>
>>>   to
>>>   "/usr/share/polkit-1/actions/org.kde.ktexteditor.katetextbuffer.policy"
>>>   :
>>>   Permission denied.
>>>
>>> Call Stack (most recent call first):
>>>   cmake_install.cmake:77 (include)
>>>
>>> ```
>>>
>>> I can workaround this by either commenting out the kauth install bits in
>>> ktexteditor or by installing kauth seperately too. But both are in my
>>> opinion not ideal.
>>>
>>> I don't think it's currently possible to overwrite the KAuth install
>>> directory at cmake configure time. I would like to change that, unless
>>> there is something I'm missing which would prevent this? I am hoping that
>>> any folder works as long as it's listed in the `XDG_DATA_DIRS` env var -
>>> can someone confirm this?
>>
>> Alas, the path is hardcoded at buildtime from what I see:
>> https://gitlab.freedesktop.org/polkit/polkit/-/blob/master/src/polkitbackend
>> /polkitbackendinteractiveauthority.c#L302
>>
>> Relevant: https://bugs.kde.org/show_bug.cgi?id=425272
> 
> So the path that needs to be used is actually the polkit path?

That's my understanding of the code, yes.

> Meaning the 
> question where KAuth is being installed to doesn't really matter? That would 
> imply that KAuth is broken anyways when it's not installed to the same prefix 
> that polkit is being installed to, no?

Nope. If the policy was installed to a different path it would be
broken, but the very error you posted is because kauth is insisting on
putting the policy in the correct path rather than the prefix the rest
of the build is installing to.

HS



signature.asc
Description: OpenPGP digital signature


Re: CMake kauth_install_* with system kauth and user CMAKE_INSTALL_PREFIX

2020-10-19 Thread Milian Wolff
On Montag, 19. Oktober 2020 11:27:29 CEST Harald Sitter wrote:
> Yo
> 
> On 18.10.20 10:11, Milian Wolff wrote:
> > Hey all,
> > 
> > since some time now I'm only compiling parts of KF5 selectively into a
> > custom prefix. Most notably, I'm only interested in ktexteditor and
> > syntax- highlighting, and would like to obtain all other frameworks
> > through my distribution packages.
> > 
> > Sadly, this doesn't work as easily, as ktexteditor is trying to do this:
> > 
> > ```
> > install(TARGETS kauth_ktexteditor_helper DESTINATION $
> > {KAUTH_HELPER_INSTALL_DIR} )
> > kauth_install_helper_files(kauth_ktexteditor_helper
> > org.kde.ktexteditor.katetextbuffer root)
> > kauth_install_actions(org.kde.ktexteditor.katetextbuffer buffer/
> > org.kde.ktexteditor.katetextbuffer.actions)
> > ```
> > 
> > Because my KAuth is a system-provided installation, and KTextEditor should
> > be installed into a user-writable prefix, I get this error on `ninja
> > install`:
> > 
> > ```
> > 
> > CMake Error at src/cmake_install.cmake:143 (file):
> >   file INSTALL cannot copy file
> >   "/home/milian/projects/kf5/build/frameworks/ktexteditor/src/
> > 
> > org.kde.ktexteditor.katetextbuffer.policy"
> > 
> >   to
> >   "/usr/share/polkit-1/actions/org.kde.ktexteditor.katetextbuffer.policy"
> >   :
> >   Permission denied.
> > 
> > Call Stack (most recent call first):
> >   cmake_install.cmake:77 (include)
> > 
> > ```
> > 
> > I can workaround this by either commenting out the kauth install bits in
> > ktexteditor or by installing kauth seperately too. But both are in my
> > opinion not ideal.
> > 
> > I don't think it's currently possible to overwrite the KAuth install
> > directory at cmake configure time. I would like to change that, unless
> > there is something I'm missing which would prevent this? I am hoping that
> > any folder works as long as it's listed in the `XDG_DATA_DIRS` env var -
> > can someone confirm this?
> 
> Alas, the path is hardcoded at buildtime from what I see:
> https://gitlab.freedesktop.org/polkit/polkit/-/blob/master/src/polkitbackend
> /polkitbackendinteractiveauthority.c#L302
> 
> Relevant: https://bugs.kde.org/show_bug.cgi?id=425272

So the path that needs to be used is actually the polkit path? Meaning the 
question where KAuth is being installed to doesn't really matter? That would 
imply that KAuth is broken anyways when it's not installed to the same prefix 
that polkit is being installed to, no?

If so, then it's just one more reason to be able to skip kauth policy 
installation, as they won't be picked up anyways...

-- 
Milian Wolff
m...@milianw.de
http://milianw.de

signature.asc
Description: This is a digitally signed message part.


Re: plasma-systemmonitor in kdereview

2020-10-19 Thread Adriaan de Groot
On 2020 tobula d. 19id 00:28:38 CEST Albert Astals Cid wrote:
> El dijous, 1 d’octubre de 2020, a les 11:36:12 CEST, Arjen Hiemstra va 
escriure:
> > I'd hereby like to announce that plasma-systemmonitor is in kdereview. It
> > can be found at https://invent.kde.org/plasma/plasma-systemmonitor .
> 
> How serious are these cmake warnings? http://paste.debian.net/1167754/

If this one error is to believed (and is faithfully cut-and-pasted):

  Error: description missing, will result in broken appdata field as
   is mandatory at
  /home/tsdgeos/devel/kde/plasma-systemmonitor/src/faces/applicationstable/
metadata.desktop
Call Stack (most recent call first):
  src/faces/CMakeLists.txt:1 (kpackage_install_package)

Then we have a typo problem somewhere else as well, since "sumary" is an 
unlikely element name.

[ade]

signature.asc
Description: This is a digitally signed message part.


Re: CMake kauth_install_* with system kauth and user CMAKE_INSTALL_PREFIX

2020-10-19 Thread Harald Sitter
Yo

On 18.10.20 10:11, Milian Wolff wrote:
> Hey all,
> 
> since some time now I'm only compiling parts of KF5 selectively into a custom 
> prefix. Most notably, I'm only interested in ktexteditor and syntax-
> highlighting, and would like to obtain all other frameworks through my 
> distribution packages.
> 
> Sadly, this doesn't work as easily, as ktexteditor is trying to do this:
> 
> ```
> install(TARGETS kauth_ktexteditor_helper DESTINATION $
> {KAUTH_HELPER_INSTALL_DIR} )
> kauth_install_helper_files(kauth_ktexteditor_helper 
> org.kde.ktexteditor.katetextbuffer root)
> kauth_install_actions(org.kde.ktexteditor.katetextbuffer buffer/
> org.kde.ktexteditor.katetextbuffer.actions)
> ```
> 
> Because my KAuth is a system-provided installation, and KTextEditor should be 
> installed into a user-writable prefix, I get this error on `ninja install`:
> 
> ```
> CMake Error at src/cmake_install.cmake:143 (file):
>   file INSTALL cannot copy file
>   "/home/milian/projects/kf5/build/frameworks/ktexteditor/src/
> org.kde.ktexteditor.katetextbuffer.policy"
>   to "/usr/share/polkit-1/actions/org.kde.ktexteditor.katetextbuffer.policy":
>   Permission denied.
> Call Stack (most recent call first):
>   cmake_install.cmake:77 (include)
> ```
> 
> I can workaround this by either commenting out the kauth install bits in 
> ktexteditor or by installing kauth seperately too. But both are in my opinion 
> not ideal.
> 
> I don't think it's currently possible to overwrite the KAuth install 
> directory 
> at cmake configure time. I would like to change that, unless there is 
> something I'm missing which would prevent this? I am hoping that any folder 
> works as long as it's listed in the `XDG_DATA_DIRS` env var - can someone 
> confirm this?

Alas, the path is hardcoded at buildtime from what I see:
https://gitlab.freedesktop.org/polkit/polkit/-/blob/master/src/polkitbackend/polkitbackendinteractiveauthority.c#L302

Relevant: https://bugs.kde.org/show_bug.cgi?id=425272

HS



signature.asc
Description: OpenPGP digital signature


Re: Windows CI Updated to Qt 5.15 - Temporarily KO due to Breeze Icons Breakage

2020-10-19 Thread Ben Cooksley
On Mon, Oct 19, 2020 at 10:35 AM David Faure  wrote:

> On mardi 6 octobre 2020 11:59:34 CEST Ben Cooksley wrote:
> > Hi all,
> >
> > This evening i've completed updates to the Windows CI system, bringing it
> > from the previous Qt 5.14 setup it was using up to the more recent Qt
> 5.15.
> > As part of this various other libraries will have also been updated.
> >
> > This update was prompted by an unannounced dependency change within
> Breeze
> > Icons. As a reminder to all developers, it is imperative that any change
> to
> > your dependencies on a non-KDE project be announced two weeks or more in
> > advance.
> >
> > Unfortunately due to regressions within Breeze Icons, it is not possible
> > for the Dependency Builds to complete at this time, meaning Windows CI
> > functionality will be generally unavailable until this is corrected.
> >
> > The failure log can be found at
> >
> https://build.kde.org/job/Administration/job/Dependency%20Build%20Extragear%
> > 20stable-kf5-qt5%20WindowsMSVCQt5.15/lastFailedBuild/console
>
> That looks like the usual java timeout
>

At the time the link was sent, it referred to
https://build.kde.org/job/Administration/job/Dependency%20Build%20Extragear%20stable-kf5-qt5%20WindowsMSVCQt5.15/2/console
which was a compilation failure.


>
> I re-ran the exact same job and it passed.
>

Things are correct now yes.


>
> Can you re-enable normal CI service for Windows?
> I noticed e.g. that KIO tests were not run anymore...
>

Normal CI service has already been restored.

Execution of KIO's tests has been disabled as they very reliably leave
behind a kioslave5.exe process which cannot be terminated except by human
intervention (at least not using the tools i've tried using). This latent
process causes not only the KIO build to fail at the end, but also causes
all other builds assigned to that builder to fail until manual intervention
takes place.

It is not known what KIO is doing that causes this issue - however I have a
suspicion it is something to do with threads.


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